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control program by the problem programmer. Complete 
descriptions of QTAM macro instructions are included. 
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QTAM to support a message processing program, refer to 
IBM System/360 Operating System; QTAM Message Process- 
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PREFACE 



This publication contains information about 
use of the facilities of the Queued Tele- 
communications Access Method (QTAM) to con- 
struct a message control program to support 
a telecommunications application- A com- 
panion publication, IBM System/360 Operat- 
ing System: QTAM Message Processing Pro- 
gram Services ,, Form C30-2003, provides 
information about constructing message pro- 
cessing programs that may be required in 
addition to the message control program - 

The reader should be familiar with the 
programming concepts and terminology intro- 
duced in the following publications: 



IBM System/360 Operating System: 

Introduction , Form C28-6534 

Concepts and Facilities ,, Form C28-6535 

Job Control Language , Forir C28-6539 

Assembler Language , Form C28-6514 

Supervisor and Data Management Services , 
Form C28-6646 

Supervisor and Data Management Macro- 
Instructions , Form C28-6647 

The reader should also be familiar with 
those of the following publications that 
apply to equipment in his system 
configuration : 

Direct Access Storage Devices: 

IBM System/360 Component Description: 
2 314 Direct Access Storage Facility and 
2844 Auxiliary Storage Contrcl , Form 
A26-3599 

IEM System/360 Component Descriptions: 
28 41 Storage Control , 



2 302 Disk Storage Models 3 and 4„ 
2 311 Disk Storage Drive, Model 1, 
2321 Data Cell Drive, 
2303 Drum Storage ,, 
Form A26-598 8 



Telecommunications Control Units: 

IBM 2701 Data Adapter Unit, Principles 
of Operation , Form A22-68 64 

IBM System/360 Component Description: 
IBM 2702 Transmission Control ,, Form 
A22-6846 

IBM System/360 Component Description : 
IBM 2703 Transmission Control ,,, Form 
A27-2703 

Terminal Equipment: 

IBM 103 Data Collection System ,, Form 
A24-3018 

IBM 1050 Data Communication System: 
Principles of Operation , Form A24-3474 

IBM 1060 Data Communication System , Form 
A24-3034 

IBM System/ 360 Component Description: 
IBM 2260 Display Station, IBM 2848 Dis- 
play Control , Form A27-2700 



IBM 27 40 Communications Terminal , Form 
A24-3403 

Model 20 Functional Characteristics ., 
Form A26-5847 

Users lacking a background in data com- 
munications concepts should read: 

Data Communications Primer ,, Form 
C20-1668 

IBM System/ 360 Introduction to Tele- 
processing , Forir C30-2007 
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INTRODUCTION 



In the IBM System/360 Operating System, an 
access method is a procedure for transfer- 
ring data between main storage and an 
input/output device. A variety of access 
methods is available to the user of the 
operating system (OS) . One of these, the 
Queued Telecommunications Access Method 
(QTAM) , controls data transfer between main 
storage and remote terminals connected to 
an IBM 2701, 2702 or 2703 control unit that 
is attached to the multiplexer channel. 

QTAM is a generalized input/output con- 
trol system that extends the techniques of 
data management to the telecommunications 
environment. Data sets accessed by the 
problem programmer are queues of messages 
coming in from,, or going out to, remote 
terminals via communication lines. Even 
though the time and order of the arrival 
and departure of messages to and from the 
Central Processing Unit (CPU) are unpre- 
dictable, the programmer can handle the 
messages as if they were sequentially 
organized. 

Unlike other commonly used access 
methods, QTAM furnishes more than just the 
mechanics for input/output operations,. In 
addition to the standard GET/PUT macro 
instruction support for message processing 
programs,, QTAM provides a high-level* flex- 
ible message control language. QTAM- 
supplied macro instructions can be used to 
construct a complete message control pro- 
gram that controls the flow of message 
traffic from one remote terminal to another 
(message switching application), and 
between remote terminals and any message 
processing programs (message processing 
applications). An installation-oriented 
message control program can thus be written 
in a shorter time than was previously 
possible* 

A QTAM message control program is 
generated from a number of assembler macro 
instructions coded by the programmer. 
Although the assembler macro-generator is 
used, the process followed is similar to 
that used by a high-level coirpiler. A QTAM 
message control program is open-ended. The 
user can include functions not provided 
through the QTAM language by employing OS 
control program macro instructions, and 
assembler language instructions and macro 
instructions . 

A message control program is completely 
device dependent, with all communication 
lines and terminals identified to the sys- 
tem. Through data set definition and 



control- information macro instructions j, the 
user specifies his equipment configuration 
and the areas in main storage (buffers) 
required for his applications. These 
macros generate the tables and lists of 
control information that define the 
environment of the system for the QTAM 
logic. Buffers are one of the primary 
resources in the telecommunications system. 
The number and size of the buffers required 
for an application are specified by the 
user. The buffers are allocated to a com- 
mon buffer pool from which QTAM automatic- 
ally and dynamically obtains them in accor- 
dance with immediate requirements, 

QTAM logic modules are also provided for 
many procedural functions,, such as message 
code translating, routing of messages, and 
error checking. By selecting the appropri- 
ate macro instructions, the user specifies 
which QTAM logic modules are to be incorpo- 
rated into his message control program. In 
this way„ the system can be tailored to the 
exact requirements of the applications 
being supported. 

The message processing program services 
of QTAM enable a programmer to process mes- 
sages from a telecommunications network 
with the same easy-to-use macro instruc- 
tions that he uses for his local input/ 
output devices. When a QTAM message con- 
trol program performs the input/output 
operations* a device- independent message 
processing program can be written. The 
applications programmer is shielded from 
the time and device-dependent aspects of 
the telecommunications environment. 

This publication is devoted primarily to 
the QTAM facilities provided for the con- 
struction of a message control program. 
Message processing programs are discussed 
in general terms and cnly when necessary to 
give a complete picture of a QTAM- 
controlled telecommunications system. For 
detailed information on message processing 
programs and the services QTAM provides in 
supporting them,, refer to IBM System/360 
Operating System; QTAM Message Processing 
Program Services . 



TERMINAL TYPES SUPPORTED 



OS QTAM supports the following types of 
terminals attached to a System/360 multi- 
plexer channel through a telecommuni- 
cations control unit (IBM 2701 Data Adapter 
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Unit or 2702 or 2703 Transmission Control 
Unit): 



MACHINE AND DEVICE REQUIREMENTS 



• IBM 1030 Data Collection System on a 
nonswitched network (1031,1033 only). 

• IBM 1050 Data Communication System on a 
switched network or a nonswitched 
network. 

• IBM 1060 Data Communication System on a 
nonswitched network. 

• IBM 2260-2848 Display Coirplex (remote) 
on a nonswitched network (2701 only) 
(1053 is not supported when attached to 
a 2848). 

• IBM 2740 Communications Terminal on a 
nonswitched network — four types: 
Type I: Basic 2740 

Type III: Basic 2740 with Station 
Control 

Type IV: Basic 2740 with Station Con- 
trol and Checking 

Type VI: Basic 2740 with Checking 

• IBM 2740 Communications Terminal on a 
switched network -- four types : 

Type II: Basic 2740 

Type V: Basic 2740 with Transmit 

Control and Checking 
Type VII: Basic 2740 with Checking 
Type VIII: Basic 2740 with Transmit 

Control. 

• IBM 2740 Model 2 Communication Terminal 
on a nonswitched network when equipped 
with Station Control, with cr without 
Checking, with or without Buffer 
Receive. 

• AT&T 83B3 Selective Calling Stations on 
a nonswitched network. 

• Western Union Plan 115A Outstations on 
a nonswitched network. 

• Common Carrier (8-level code) TWX Sta- 
tions on a switched network (for 
example,, ATST Model 33 or 35 Teletype- 
writer Terminal, dial service) 

• World Trade telegraph terminals (WTTA 
terminals) on a nonswitched network, 
attached through a 2701,, 2702, or 2703 
that contains a World Trade Telegraph 
Adapter. 



Note : Throughout this publication,, "World 



A QTAM message control program can be coded 
to operate in a minimum size partition of 
main storage (for estimates of core storage 
required for QTAM functions, see the publi- 
cation IBM System/3 60 Operating System: 
Storage Estimates , Form C28-6551,. ) Message 
queues may be maintained on multiple 
volumes on either 2311 direct access 
storage devices* or on 2314 direct access 
storage devices. The only additions to the 
minimum requirements of the IBM System/360 
Operating System are: 

• All telecommunications terminals must 
be attached to an IBM 2701 Data Adapter 
Unit or a 2702 or 2703 Transmission 
Control. They cannot be attached 
directly to a channel. 

• All IBM 2701,, 2702, * and 2703 control 
units operating under QTAM control must 
be attached to the System/360 via the 
multiplexer channel. 

• The hardware timer feature must be pre- 
sent. At system generation time w the 
user must specify that the timer facil- 
ities are to be included. 

• The 1033 output station requires the 
insertion of three idle characters 
(hexadecimal 'DF DF DF') prior to each 
character transmitted to it,. The user 
may insert them either in his LPS or in 
a message processing task. 

• No device may be operated in burst mode 
on the multiplexer channel concurrently 
with QTAM operation. 

• All switched lines that are to allow 
computer-initiated transmissions must 
have the Auto Call feature, that is: 

IBM 10 50 on a switched line network, 
IBM 2740 Type II, V, VII, and VIII on a 
switched network. 

Common carrier (8-level code) TWX sta- 
tion on a switched network. 

• The user must understand that the high 
rate of data transfer between the CPU 
and the 2260 display station can cause 
the display screen to fill up several 
times before the terminal operator has 
had time to read the initial display. 
Also„ a message being entered from a 



f 



Trade telegraph (WTTA) terminal" refers to 
a terminal as defined on page 28, connected 
through a 2701, 2702 or 2703 Transmission 
Control Unit that incorporates a World 
Trade Telegraph Adapter. A "World Trade 
(WTTA) line" is a line connected in the 
same manner to a World Trade terminal. 



*A switch on the CE panel on a 2702 can be 
used to place a given line in CE mode for 
equipment checking. Care must be taken to 
insure that no lines are in CE mode when 
using QTAM since no ending status would be 
returned to a SIO command. 



2260 display station may be destroyed 
if a message being sent from another 
terminal comes in before his unit has 
been polled and the message sent. 

The following additional features may be 
required if certain optional functions pro- 
vided by QTAM are desired: 

• The line correction feature on IBM 1050 
terminals, if automatic retry of mes- 
sages from a car d reader or tape reader 



is desired wheria~Transmissxon error 
occurs. 

• The automatic polling feature (Auto 
Poll) on the IBM 2703 Transmission Con- 
trol Unit, if automatic polling of the 
following terminal types (attached to 
the multiplexer channel through a 2703) 
is desired: 

IBM 1030. 
IBM 1050. 
IBM 1060. 

IBM 2740 with Station Control. 
IBM 2740 with Station Control 
and Checking. 

The Auto Poll feature is standard on 
the 2703 Transmission Control. 



GENERAL REQUIREMENTS AND CAPABILITIES 



To construct a telecommunications system 
that will operate under control of QTAM (in 
the operating system environment) the user 
must write: 

1. A message control program, 

2. Any message processing programs 
required by his application. 

A telecommunications control system 
created through the use of the QTAM message 
control language can: 

• Establish contact and control message 
traffic between computer and remote 
terminals. 



Maintain statistical information about 
message traffic. 



OPERATING SYSTEM CONSIDERATIONS 



QTAM is designed to operate in either 
Option 2 (Multiprogramming With a Fixed 
Number of Tasks) or Option 4 (Multiprogram- 
ming With a Variable Number of Tasks) of 
the IBM System/360 Operating System,. Dis- 
cussions in this publication assume that 
Option 2 is being used; however,, all infor- 
mation applies equally to Option 4. 

Under Option 2,, it is suggested that the 
message control program reside in partition 
0„ while any message processing programs 
are in lower priority partitions,. In 
Option 4„ it is suggested that the message 
control program be the highest priority job 
in the system. 



NACRO INSTRUCTION FORMATS 



A coding format illustration accompanies 
each macro instruction description in this 
publication. The illustrations indicate 
which operands must be coded exactly as 
shown, which are variable, which are 
required*, which are optional,, etc. The 
following system of representation is used 
to describe the macro instruction operands. 

1. Both positional and keyword operands 
are described by a 3-part structure. 
Positional operands are described by a 
lowercase name followed by a hyphen 
and a value mnemonic or a coded value. 

Example: termname- chars,. The lower- 
case name, termname,, is merely a con- 
venient reference to the operand and,, 
along with the hyphen and value mne- 
monic,, is never coded by the program- 
mer, The programmer replaces the 
positional operand in his coding by an 
allowable expression defined by the 
value mnemonic. 



• Dynamically allocate main storage for 
buffering. 

• Perform editing of incoming and outgo- 
ing messages '(i.e. , code translation, 
insertion of new fields in message 
headers) . 

• Forward messages to destination ter- 
minals and message processing programs. 

• Take corrective action and provide spe- 
cial handling for messages containing 
errors. 



2. 



For keyword operands,, the 3-part 
structure consists of the keyword* 
followed by an equal sign (both of 
which must be coded as shown) , fol- 
lowed by a value mnemonic or coded 
value that describes what to code on 
the right side of the equal sign. 
Keyword operands are coded with 
separating commas. 

Example : CALL=integer 

Coded values are written in the format 
description as uppercase characters 
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and must be coded exactly as shown in 
the format. 

3. Value mnemonics are written as lower- 
case characters in the format descrip- 
tions and indicate how an operand is 
to be coded by the programmer. The 
value mnemonics used in this publica- 
tion are: 

symbol Any symbol that the assem- 
bler accepts in the name 
field of an instruction. 

relexp A relocatable expression 

(acceptable as an A-type or 
V-type address constant by 
the assembler) . 

addx Any indexed (implied or 
explicit) or nonindexed 
(implied or explicit) 
address (acceptable as an 
operand in the RX type 
assembler instruction). 



4. 



(r) Register notation. This 
notation specifies, by an 
absolute expression enclosed 
in parentheses, any register 
2-12. It also allows the 
programmer to load the spec- 
ified register with the 
appropriate value at execu- 
tion time. Certain macro 
instructions also permit use 
of registers and 1 by spe- 
cifying (0) or (1). The 
or 1 within parentheses must 
be coded. 



{ } [ ] Braces or brackets are used 
to define grouping of the alternate 
forms of an operand. 



When braces { } are used, the user 
must code one of the choices - in the 
following exairple., T or L. 



code One of the coded values 

defined as allowable by the 
individual macro 
instruction. 



Example; qtype - 



m 



absexp Any absolute expression as 
defined by the 
assembler: self-defining 
terms (decimal, hexadeci- 
mal, binary, character), 
length attributes, absolute 
symbols, paired relocatable 
terms in the same CSECT, and 
arithmetic combinations of 
absolute terms,. 



When brackets are used, the user may 
code any of the choices shown. If he 
omits the operand* the underlined 
choice is assumed by the system. 



Example: 



CPRI=R 
CPRI=E 
CPRI=S 



integer A decimal self-defining 
term. 

chars A character string (the 

framing characters, C * , 
are not coded unless specif- 
ically indicated in the 
individual macro instruction 
description) . 

text Same as chars . 

hexchars Concatenated hexadecimal 

digits (the framing charac- 
ters, X" \, are not coded 
by the prograirmer unless 
specifically indicated in 
the individual macro 
instruction description) . 



Brackets containing only one form of 
an operand indicate an optional 
operand, 



Example : [ nn ] 



5, ... Ellipsis (three periods) indi- 
cates that the operand can be coded 
one or more times. 



Parentheses and commas must be coded 
where indicated. No commas should 
appear after the last operand coded by 
the programmer, Descriptive symbols 
are not to be coded by the programmer. 
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QT AM- CONTROLLED TELECOMMUNICATIONS SYSTEMS: CONCEPTS AND TERMINOLOGY 



This section describes the characteristics 
and operating concepts of a computer-based,, 
QTAM-controlled telecommunications system: 
what it is,, how its parts are connected, 
how communication proceeds,, and how control 
is maintained. A number of terms that are 
used throughout the publication are 
defined. For ease of reference, many of 
these terms also appear in the glossary of 
this publication. 



Telecommunications systems vary consi- 
derably from one another in terms of the 
uses to which they are put, the component 
parts of which they consist, the nature of 
the message traffic accommodated* the means 
of controlling the system, etc. Many of 
the techniques and terms explained are 
characteristic of telecommunications sys- 
tems, either specifically or in general- 
Certain definitions may be at a slight 
variance with the reader's previous 
experience. This arises because* over the 
years, technical literature has contributed 
a number of conflicting or ambiguous 
definitions and because it is desirable to 
make certain generalizations to avoid a 
level of detail inappropriate to the needs 
of the QTAM programmer. Therefore,, the 
techniques and terms explained in the fol- 
lowing discussion should be understood as 
applying specifically to a computer-based 
telecommunications system that operates 
under the control of the QTAM facility of 
the IBM System/360 Operating System. 



A telecommunications system (or network) 
consists of a number of input,, output, or 
combined input/output devices, usually in 
geographically dispersed locations* con- 
nected by one or more communications lines. 
A telecommunications system operating under 
OS QTAM may be specifically defined as a 
network of terminals connected to a central 
computer by one or more half-duplex com- 
munication lines. (A half -duplex line is a 
line over which data can flow in either 
direction, but in only one direction at a 
time. ) 

In communications terminology* the fol- 
lowing terms are used to represent the 
medium that connects the physical com- 
ponents of a system: communication line, 
data link, data path, circuit, and channel. 
In this publication the term communication 
line (or line ) is used to refer to any 
medium, whether it is a telegraph circuit,, 
a telephone circuit, a private circuit, 
etc. 



A terminal is the unit or units of 
equipment that accepts keyed or punched 
data as input for sending to the computer 
and/or produces printed, punched* or visu- 
ally displayed data as output received from 
the computer. All messages from one termi- 
nal to another pass through the computer. 
In addition,, the computer can receive and 
originate messages for the terminals. 

A terminal consists of a control unit 
and one or more input/output devices. Each 
such device is called a component . Each 
input and output device is considered a 
separate component, regardless of whether 
they are physically combined. For example, 
an IBM 1050 is referred to as a terminal; 
its constituent devices, or components, 
include the IBM 1053 Printer,, the 1054 
Paper-Tape Reader, the keyboard section of 
the 1052 Printer-Keyboard,, the printer sec- 
tion of the 10 52 Printer-Keyboard* etc. 

Terminal is used as a general term to 
represent the equipment at the remote loca- 
tion. Component is used, where necessary, 
to distinguish between the individual 
devices and the terminal as a whole. Sta- 
tion is used to represent the remote loca- 
tion at which a terminal is situated. 

Terminals in a telecommunications system 
operating under OS QTAM control are usually 
separated from the computer by a distance 
sufficient to require common-carrier facil- 
ities and transmission techniques in order 
to accomplish communication with the com- 
puter. The system, however* may include 
terminals on the same premises as the com- 
puter* attached to it by local cables. 
Regardless of the location of the terminal, 
all supported terminals are classified as 
"remote" since they must be attached to the 
computer channel via a Telecommunications 
Control Unit (TCU ) , The TCU may be an IBM 
2701 Data Adapter Unit,, or a 2702 or 2703 
Transmission Control Unit, OS QTAM does 
not support "local" terminals that are 
directly connected to a System/360 channel. 

Each remote terminal and TCU is con- 
nected to the communications line by a type 
of data set,, modem (modulator/demodulator) , 
line adapter, subset,, etc. , depending on 
the kind of communication line and type of 
terminal involved. (Terminals connected to 
the TCU by local cables do not require data 
sets.) The precise functions of these 
units vary, but the overall purpose is the 
same: to provide an electrical interface 
between terminal and line, This publica- 
tion uses the more common term data set to 
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represent any of these units (not to be 
confused with a program data set),. The 
programmer need not concern himself with 
these data sets. They are mentioned only 
to provide a complete picture of the line 
and terminal configuration. 

In this publication, computer is used as 
a general term for the equipment and pro- 
grams at the central processing location 
(CPU, TCU, etc.), when reference to a spe- 
cific unit of equipment or programming is 
not necessary. 



TELECOMMUNICATIONS NETWORKS 



A telecommunications system rray consist of 
a nonswitched network, a switched network,, 
or a combination of the two. 

A nonswitched network consists of a num- 
ber of private (or leased) lines that con- 
nect the computer to one or. more remote 
terminals,. The computer and the terminals 
are physically connected; that is,, the cir- 
cuits making up the communications lines 
are continuously established for predeter- 
mined time periods during which data trans- 
mission may proceed between the computer 
and the terminals,. Under certain condi- 
tions in this type of system,, the computer 
can send messages to more than one terminal 
on the same line at the same time. The 
lines that comprise a nonswitched network 
are known variously as private, leased, or 
dedicated lines,. These lines usually are 
furnished by a common carrier on a contract 
basis, between specified locations for a 
continuous period or regularly recurring 
periods at stated hours, for the exclusive 
use of one customer. See Figure 1. 

A switched network consists cf a number 
of remote terminals with which the computer 
can communicate. The computer and the sev- 
eral terminals are connected by access 
lines to the common-carrier exchanges serv- 
ing their respective locations . A complete 
and continuous data path is established 
between computer and terminal only for the 
period of time in which transmission takes 
place. The connection is established by 
dialing the telephone number of the unit 
(either terminal or CPU) at the other end„ 
In this type of system, communication can 
be established between the computer and 
only one terminal at a time on each line. 



In this case,, line refers to a discrete 
data path between the telecommunications 
control unit and the common- carrier 
exchange. The service provided by the com- 
mon carrier is typically on a time-used 
basis. See Figure 2. 

In a nonswitched network, the physical 
circuit connections determine which ter- 
minals are associated with each line into 
the computer. In a switched network, the 
user specifies which terminals can commun- 
icate with the computer over each line. 

Some communication networks have charac- 
teristics typical of both switched and non- 
switched networks^ In this publication, 
the term switched network refers to any 
network in which a direct physical connec- 
tion between computer and terminal must be 
established by dialing in order for data 
transmission to occur. The term non- 
switched network refers to a network in 
which the communication lines linking com- 
puter and terminals are continuously estab- 
lished, thus requiring no dialing. 



MESSAGE CONTROL 



The QTAM message control facilities accom- 
plish efficient, systematic supervision of 
message traffic. In some respects,, the 
functions performed by QTAM message control 
procedures parallel those performed in 
telecommunications systems that are not 
computer-oriented. 

This section provides a general descrip- 
tion of telecommunications systems followed 
by a discussion of the main functions per- 
formed in a computer-based system operated 
under QTAM control, Subsequent sections of 
this publication explain how these func- 
tions are implemented. 

Generally,, in any telecommunications 
system, contact between terminals must be 
established before a message is sent. In 
some systems,, terminals attempting to send 
a message contend with one another for use 
of the line. The first terminal to initi- 
ate contact on a line that is not currently 
in use seizes the line and prevents its use 
by other terminals until it has concluded 
its message transmission- A system 
operated in this manner is called a conten- 
tion system. 
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Figure 2. Line and Station Configuration: Switched Network 



In other systems, one of the terminals 
is specified as the control station . This 
terminal initiates all contacts for all 
other terminals on the line, using a proce- 
dure known as polling. Polling is a flex- 
ible, systematic, centrally controlled 



method of permitting terminals on a multi- 
terminal line to transmit without contend- 
ing for use of the line. The control sta- 
tion periodically contacts the other ter- 
minals and invites them to send any mes- 
sages they have ready. In addition* the 
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control station itself may elect to send a 
message. A system operated in this manner 
is called a polling system. 

Polling is accomplished by sending one 
or more polling addresses on the line, each 
of which consists of one or more polling 
characters . Typically, two characters are 
used; the first selects the terminal, the 
second selects the specific component of 
that terminal.. The terminal identified by 
these characters then sends a response to 
the control station - a positive response 
if it has a message to send, a negative 
response if it does not. The control sta- 
tion may poll a number of terminals and 
components in turn until one is found that 
has a message ready. 

Similarly, when the control station ter- 
minal (or any other terminal) has a message 
to send, it transmits one or more address- 
ing or call-directing characters on the 
line. As in polling, two characters are 
usually used: the first selects the termi- 
nal, the second selects the component. The 
terminal identified by these characters 
returns a response. A positive response is 
returned if the terminal is able to accept 
the message; a negative response is 
returned if the terminal cannot accept the 
message. 

A QTAM- control led telecommunications 
system is oasically a polling system in 
which the computer acts as the control sta- 
tion (although certain types of the IBM 
27 40 Communication Terminal employ techni- 
ques similar to those used by a contention 
system) . Moreover, it is a centralized 
system in that terminals send their mes- 
sages to the computer instead of to other 
terminals. The computer then relays the 
messages to the appropriate destination 
terminals (or to a message processing 
program) ,. 

With minor variations, the polling and 
addressing functions are performed in both 
switched and nonswitched systems. 

In a switched network, the line connec- 
tion must be completed between computer and 
terminal before message transmission can 
proceed. The connection may be established 
by either the computer or a terminal. 

In order to establish the connection, 
the computer dials the telephone number of 
the terminal. (The user provides QTAM with 
the telephone number of each terminal in 
the switched network.) The connection is 
established when the terminal responds. 
The function performed by the computer in 
this case is known as calling . Polling or 



addressing may then take place. Ordinari- 
ly, the computer calls a terminal only to 
address the terminal (to send it a mes- 
sage) , rather than to poll it (to solicit 
messages) . 



When a terminal is to establish the con- 
nection,, the operator at the terminal dials 
the telephone number of one of the compu- 
ter's access lines. The connection is 
established when the computer responds. 
The function performed by the computer, in 
this case, is known as answering . Polling 
or addressing may then take place. 
Ordinarily,, a terminal calls the computer 
only when the terminal is to be polled for 
a message it has ready for the computer or 
another terminal. Regardless of whether 
the computer or the terminal establishes 
the line connection, message flow from the 
terminal to the computer is achieved by 
polling the terminal. Message flow from 
the computer to a terminal is achieved by 
addressing the terminal. 

Although terminals are permitted to call 
the computer at any time* the computer, in 
order to fulfill its function as control 
station,, must be able to accept or reject 
incoming calls. Therefore, the computer 
performs a function known as enabling the 
line ,, which is the process of conditioning 
the telecommunications control unit to 
accept incoming calls on a line,. The user 
determines which lines are to be enabled,, 
at a given moment, and which are not. If a 
terminal calls in on a line that is cur- 
rently enabled and that is not in contact 
with another terminal, the line connection 
is completed and message transmission (pre- 
ceded by polling or addressing) can occur. 
If a terminal calls in on a line that is 
enabled but is occupied with another termi- 
nal, the calling terminal receives a busy 
signal, and contact is not established* If 
a terminal calls in on a line that is not 
currently enabled,, the TCU cannot answer 
the call. Ringing continues until the 
operator hangs up.. In either of the latter 
two cases, the terminal must wait and call 
again later. 

In a nonswitched network, the line con- 
nections between computer and terminals are 
continuously established; hence, the call- 
ing, answering, and enabling functions are 
not required. Only the computer can initi- 
ate contact with remote terminals (except 
for Types I„ II„ VI,„ and VII of IBM 2740 
Communications Terminals, which can bid for 
the computer's attention). Even in this 
instance,, however, QTAM must previously 
have issued a command that permits the TCU 
to respond to a bid from the 2740. 
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MESSAGE PROCESSING 



Message processing is the most variable of 
all telecommunications functions. The 
nature of each user's processing routines 
depends on the individual application. 

QTAM provides macro instructions en- 
abling the user's problem program to obtain 
messages queued for processing and to place 



response messages on destination queues. 
These macro instructions,,, GET and PUT* 
together with associated OPEN and CLOSE 
macros, are presented in the publication 
Operating System QTAM Message Processing 
Program Services . QTAM also provides a set 
of macro instructions for examining and 
modifying control information used by the 
access method. These macros are presented 
in a later section of this publication and 
in the above publication- 
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OS QTAM CONCEPTS AMD FACILITIES 



GENERAL CONCEPTS 



The function of programs constituting sup- 
port for a telecommunications system is to 
systematically and efficiently control the 
flow of data in a computer-based telecom- 
munications system, and to perform concur- 
rently any required processing cf the data. 
Data enters the system randomly in the form 
of message blocks from terminals and/or 
from programs that generate messages. The 
messages entered at the terminals consist 
of two principal parts: the message head- 
er, containing only control information, 
and the message text or data. Data is 
ultimately delivered to one or more ter- 
minals and/or programs that process 
messages. 

For a number of reasons, the support is 
logically divided into two categories: 

1. Programming required to identify the 
telecommunications system to the IBM 
System/360 Operating System, to estab- 
lish the line control disciplines 
required for the various types of ter- 
minals and modes of connection, and to 
control the routing of messages in 
accordance with the user* s 
requirements . 

2. Programming required to process the 
contents of the messages. 

The first category is implemented by rou- 
tines collectively known as the message 
control program , which is primarily con- 
cerned with the message header. The second 
category is implemented by one or more mes- 
sage processing programs , which are pri- 
marily concerned with the message text or 
data. 

The paramount reason for dividing tele- 
communications support into these two types 
of programs is that message flow in the 
system is random and proceeds at relatively 
slow speeds (owing to the operating speeds 
of the terminals) while the messages, once 
delivered to the computer, can be processed 
at computer speeds, To fully utilize the 
computing system capabilities, message 
traffic must proceed asynchronously with 
message processing. Another reason for 
having separate message control and message 
processing programs is that while many 
device-dependent considerations govern the 
design of a message control program, they 
do not affect the design of a message pro- 
cessing program. The programmer writing a 



message processing program need know only 
the format of the messages and the charac- 
teristics of the data they contain to be 
able to proceed with the program design. 

A message control program serves as an 
intermediary between the remote terminals 
and any message processing programs- The 
device- dependent input/ output operations 
are performed by QTAM routines that support 
the message control program, and are based 
on the terminal and line configuration of 
the user's system as specified in the 
operands of QTAM macro instructions. To 
provide maximum efficiency, QTAM uses the 
operating technique of placing messages on 
queues on a direct access storage device 
(DASD) , when necessary, and subsequently 
retrieving these messages for processing. 

The message control program can perform 
limited processing of the message, in addi- 
tion to that performed by a message pro- 
cessing program. Some of these processing 
operations may be required in order for the 
message control program to perform its 
function; for example, scanning the header 
to determine routing information^, and mes- 
sage code translating. Other optional pro- 
cessing operations are provided by QTAM as 
a convenience to the user. For example, 
the message control program can insert the 
time of day in message headers, obviating 
the need for a message processing routine 
to do this. 

Every telecommunications system operated 
under QTAM requires one and only one mes- 
sage control program. Depending on the ap- 
plication, one or more message processing 
programs may be required, or none at all 
(except that a message processing program 
is always necessary tc deactivate the tele- 
communications system) . An example of an 
application requiring no concurrently run- 
ning message processing program is a 
message-switching application, The sole 
function of its telecommunications support 
is to receive messages from terminals and 
forward them unaltered (except for such 
processing as the message control program 
may perform) to one or more terminals. 

A telecommunications system may include 
several different terminal types,, and both 
line types (switched and nonswitched) . For 
each combination of line and terminal type, 
the user must specify a sequence of QTAM 
message control macro instructions. In 
general, a separate sequence must be writ- 
ten for each communications line group . A 
communications line group consists of one 



~7\ 



OS QTAM Concepts and Facilities 17 



or more communication lines of the same 
type, over which the same type of terminal 
can communicate with the computer. Each 
^sequence of message control macro instruc- 
tions is called a line procedure specifica- 
tion (LPS); the several LPSs collectively 
constitute the heart of the message control 
program. 

Example : Assume that a telecommunications 
system is to consist of four nonswitched 
lines to which IBM 1050 terminals are con- 
nected, one switched line over which con- 
tact with IBM 1050s can be made, three non- 
switched lines to which IBM 2260s are con- 
nected, and two switched lines over which 
contact with TWX terminals can be made. 
The system would then have four line 
groups : 

1. A nonswitched 1050 group. 

2. A switched 1050 group. 

3. A nonswitched 2260 group. 

4 . A switched TWX group. 

A separate LPS would be required for each 
group. 

Each LPS consists of user-selected macro 
instructions in two groups: a 'receive 
group, ' which defines the routines required 
to operate on messages coming in from any 
line in the line group, and a 'send group, ' 
which defines routines required to operate 
on messages going out to any line in the 
line group. 



THE OPERATING ENVIRONMENT 



When QTAM is operating under supervision of 
Option 2 (Multiprogramming with a Fixed 
Number of Tasks) of the System/360 Operat- 
ing System, the message control program and 
each of the message processing programs are 
executed as separate jobs. The message 
control program must be executed as the 
highest-priority job and hence must be 
loaded into partition 0. The message pro- 
cessing programs may be located in any of 
the remaining partitions. If the message 
control job and the message processing jobs 
do not require the use of all available 
partitions, the remaining partitions may be 
used for batch processing jobs. The batch 
job(s) should be loaded into the lowest- 
priority partition (s) . 



QTAM FACILITIES 



The QTAM facilities include a comprehensive 
set of input/output, message control, 
translating, and editing routines that 



relieve the programmer of the detailed and 
specialized programming usually required in 
writing a message control program for a 
telecommunications system. Macro instruc- 
tions are provided that allow the program- 
mer to assemble and linkage edit these rou- 
tines into an integral message control pro- 
gram designed to meet the exact require- 
ments of an installation. 



The primary capabilities of the telecom- 
munication programs that can be created 
through the use of QTAM macro instructions 
are: 

• Polling terminals. 

• Receiving messages from terminals,. 

• Addressing terminals- 

• Sending messages to terminals. 

• Dynamically allocating main storage for 
buffering. 

• Performing message editing functions 
for incoming messages such as: trans- 
lating from the appropriate transmis- 
sion code to extended binary coded 
decimal interchange code (EBCDIC) ; 
inserting time-received and date- 
received information in the header; 
recording (logging) the message on a 
secondary storage medium such as mag- 
netic tape; and maintaining a count of 
the number of messages received from 
each terminal. 

• Routing messages to appropriate queues, 
determined by either the destination 
code specified in the header of the 
message „ or the source from which the 
message entered the system. 

• Queuing messages on a direct access 
storage device. 

• Initiating corrective action when an 
error or unusual condition is detected. 

• Intercepting transmission of messages 
in error. 

• Cancelling messages containing errors. 

• Rerouting messages. 

• Transmitting error messages.. 

• Routing messages with erroneous header 
information to a special queue. 

• Providing message data, in the work 
unit specified (message, message seg- 
ment, or record), to a message process- 
ing program. 



Placing response messages generated by 
message processing programs on queues 
for subsequent transmission. 

Retrieving messages already queued for 
transmission to terminals,. 

Performing message editing functions 
for outgoing messages such as: placing 
time-sent and date-sent information in 
the header, placing an output sequence 
number in the header, logging the out- 
going message on a secondary storage 
device, maintaining a count of the num- 
ber of messages sent to each terminal, 
and translating the message from EBCDIC 
code to the appropriate transmission 
code. 

Checkpointing QTAM message control pro- 
gram for subsequent restart after sys- 
tem interruption. 

Providing operator control to system 
communication through a telecommunica- 
tions system control terminal. 

Q \ • Providing on-line terminal testing for 
IBM 1030,, 1050,, 10 60, 2740, and 2260- 
2848 remote terminals. 



DATA SET DEFINITION AND CONTROL INFORMATION 



A data control block must be defined for 
each data set referred to by the message 
control and message processing programs. 
This is accomplished by means of DCB macro 
instructions. A DCB macro instruction must 
be provided for each of the following types 
of QTAM data sets: 

• Each communication line group (message 
control program) . 

• Direct access message queues (message 
control program) . 

• Checkpoint (message control program). 

• Each main storage process queue (mes- 
sage processing program) . 

• Main storage destination queue (message 
processing program) . 

Similarly, an appropriate DCB macro 
instruction must be provided for each mes- 
sage log data set used by the message con- 
trol program. The actual DCB used is a 
function of the storage medium used for the 
message log. 

The data control blocks in a message 
control program serve as logical connectors 
between the message control program and the 
associated line group, DASD message queues, 
and message log data sets,. (These data 
sets are explained in detail in later sec- 
tions of this publication.) The data con- 



trol blocks defined in a message processing 
program are not associated with data sets 
themselves. They are used to provide con- 
trol information to QTAM for the transfer 
of data to and from a message processing 
program.. The main storage process and 
destination queues are the principal con- 
nectors between a iressage control program 
and a message processing program,. 

In addition to the data set definitions , 
the user must supply control information in 
the form of macro instructions that are 
used by the message control program to con- 
trol the sending and receiving of messages. 
The control information consists of: 

• The name and address of each terminal, 
along with related information such as 
any special distribution lists for 
sending a message to more than one 
terminal, 

• The name of each DASD process queue 
associated with a message processing 
program to which incoming messages are 
to be sent. 

• A polling list for each line that indi- 
cates the order in which the terminals 
are to be polled. 

• The size and number of main storage 
buffers that are to be used for mes- 
sages being sent to and from the ter- 
minals. In order to compensate for the 
differences in the rates of information 
flow, QTAM automatically and dynamical- 
ly uses available buffers in accordance 
with immediate needs. 



MESSAGE FORMATS 



A message usually consists of two parts: 
header and text. The message header con- 
tains control information for the message 
such as : 



1. 
2. 

3. 



4. 
5. 



One or more destination codes. 
The code name for the originating 
terminal. 

The number of the message relative to 
the numbers of previous messages 
received from that terminal (input 
sequence number) . 
A message-type indicator. 
Various other fields containing con- 
trol data. 



Operations on the fields in the header are 
a primary function of the LPS-def ined rou- 
tines in the message control program. The 
length and format of the header and the 
information it contains depends solely on 
the requirements of the application and the 
user's preferences. The length may be a 
few characters or irany characters. In some 
instances, it is possible to omit headers 
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entirely. Generally, however,, some kind of 
header is provided. The text portion of a 
message consists of the information of con- 
cern to the party ultimately receiving the 
message. This party can be either a termi- 
nal, or a program that processes the text 
(message processing program) . 



The format of the message header dic- 
tates the arrangement of the message con- 
trol program to a great extent. For this 
reason, the control characters used and the 
sequence of the fields within the header 
must be predetermined so that the message 
control program for the telecommunications 
system can be properly coded. 

The destination code in the message 
header identifies the terminal or process- 
ing program to which the message is to be 
routed. The message- type indicator can be 
used to identify a header that is to be 
processed in a special manner. By insert- 
ing certain macro instructions in the mes- 
sage control program, the user can insert 
in the header such data as the date and 
time the message is received, the date and 
time it is sent, and the number of the mes- 
sage in relation to other messages sent to 
a particular terminal (output sequence 
number) . 

Depending on the type of work unit (mes- 
sage, segment, or record) with which he is 
dealing, the user must specify appropriate 
characters for control purposes. 

• A message is that unit of text that is 
terminated by an end-of -transmission 
(EOT) character. 

• A segment is that portion of a message 
contained in a single buffer, the size 
of which is specified by the user. 

• A record is that portion of a message 
terminated by any of the following 
characters: end-of -block (EOB) , end- 
of -text (ETX) , carriage- return (CR) , 
line-feed (LF), or new-line (NL) . 

• A message block is that portion of the 
message terminated by EOB. 

There are many possible variations for 
the format of a message header. The sample 



formats shown in Figures 3 and 4 are 
included simply for illustrative purposes. 

The format shown in Figure 3 could be 
used in a message switching application. 
Byte contains a machine end-of-address 
(EOA) character. When the message is 
transmitted, this character signals the end 
of nonrecorded machine control characters 
(such as addressing characters and the 
machine EOA itself) and the beginning of 
data characters. The 192 in bytes 1 
through 3 is the input sequence number. 
Bytes 5 through 7 contain the code for the 
terminal that originated the message. 
Bytes 9 through 11 and 13 through 15 con- 
tain destination codes specifying the ter- 
minals to which the message is to be sent. 
In this example, the semicolon in byte 16 
has been designated by the user as the pro- 
gram EOA character. Since some of the mes- 
sages in this application contain multiple 
destination codes, this control character 
must follow the last destination code. 
Bytes 17 and 18 contain characters specify- 
ing the priority of the message. The 
remaining portion of the message is text 
and is followed by the EOT character. 

After the message control program has 
operated on the message header and before 
the message header is transmitted to the 
destination terminals, the format of the 
message could be as shown in Figure 4* 
When the message comes into main storage, 
the message control program inserts time- 
received and date-received information in 
the header. The time-received information 
in bytes 18 through 2 5 indicates that the 
message was received at 11 hours.„ 30 
minutes, and 4 5 seconds of the date speci- 
fied in bytes 27 through 32, which is 
November 5„ 1966. Insertion of this infor- 
mation moves the priority data to bytes 33 
and 34. The message is then queued by 
priority on the direct access storage 
device. When the message reenters main 
storage prior to transmission to the 
destination terminals, the message control 
program places the output sequence number 
in bytes 3 6„ 37, and 38 of the header.. The 
original text and the EOT character follow 
the output sequence number. 

QTAM„ with its complete set of header- 
processing routines and associated macro 
instructions, allows the user to indicate 
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Figure 3. Sample Format for an Incoming Message 
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Figure 4. Sample Format for an Outgoing Message 
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the header-processing functions he wants 
performed by including the appropriate 
macro instructions in the message control 
program. In addition to those described 
briefly in this section, there are many 
other functions available such as the 
detection of incorrect or invalid informa- 
tion in the header fields. These functions 
and the relationship of the message header 
format to the design of the rressage control 
program are discussed in detail later in 
this puolication. 



MESSAGE FLOW WITHIN THE SYSTEM 



This section describes the flow of a mes- 
sage through a system operating under OS 
QTAM, from the receipt of the message at 
the computer to its transmission to a 
destination terminal. Figure 5 illustrates 
this message flow. 

The input message is prepared at a 
remote terminal. Messages may be of vari- 
able length and consist of two parts: 
header and text. When polled, the source 
terminal sends the message to the computer 
via a communication line. In Figure 5, 
step 1 shows the message passing through an 
IBM 2701, 2702; or 2703 control unit and 
the multiplexer channel, and filling avail- 
able buffers from the QTAM buffer pool. 

The user defines t-.hft aiy.e of his buffers 
in the message control program. QTAM 
inserts control information (known as a 
prefix) in the first portion of each buf- 
fer. The first 32 bytes of a buffer con- 
taining a message header are set aside for 
a header prefix generated by QTAM. This 
buffer must'contain the entire header and 
may also contain text data. The characters 
transmitted by the remote terminal begin 
filling the buffer in byte 33. The first 
22 bytes of a buffer containing text data 
only are set aside for a text prefix 
generated by QTAM. Message data begins 
filling the buffer in byte 23. 



The user can transmit single-segment or 
multisegment messages. (A message segment 
is the amount of message data that occupie 
one buffer.) In single-segment messages, 
the entire message is contained within one 
buffer. In multisegment messages, more 
than one buffer is needed for a message. 



In all but the last buffer for a multi- 
segment message, the segment containing a 
header is shorter than a segment containing 
text only. This is because the header pre- 
fix generated by QTAM is ten bytes longer 
than the text prefix. In each buffer con- 
taining intermediate text, the segments are 
the same size. In the last buffer for a 
multisegment message, the message segment 
can be any length equal to or less than the 
buffer length minus 22. 

The buffers shown in Figure 5 are each 
80 bytes in length. The first input buffer 
thus accommodates a message segment of 48 
characters; 20 constitute the header por- 
tion of the message and 28 constitute the 
text portion. In the second input buffer, 
the message segment is 58 characters; all 
of which are text data. The third and last 
input buffer contains the remaining charac- 
ters in the message. Because the input 
message is 150 characters, the message seg- 
ment size for this buffer is 44. 

As soon as a buffer is filled with the 
first segment of a message, the receive 
group portion of the line procedure speci- 
fication (LPS) performs such user-selected 
functions as: code conversion, logging, 
updating of message counts, incorporation 
of time-received and date- received informa- 
tion, and input- sequence-number checking. 
The first three functions can also be per- 
formed for text segments. In Figure 5, the 
user has specified that messages to be 
handled by a message processing program 
must have six characters of time-received 
information incorporated into the message 
header. The header information is shifted 
in the buffer the amount that was specified 
in the LPSTART macro operand for time, 
date, or sequence number so that the addi- 
tional information may be inserted in the 
correct field (see Step 2) . 



LI 
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In performing its function, the LPS 
scans and processes header fields in accor- 
dance with the order indicated by the rela- 
tive positions of the individual LPS macro 



instructions; the operations are performed 
in the buffer containing the message 
segment. 



Message Control Program 




Figure 5. QTAM Message Flow (Part 1 of 2) 
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Message Control Program 




Figure 5. QTAM Message Flow (Part 2 of 2) 



After performing these functions, the 
receive group of the LPS routes the prefix 
(minus the first eight bytes 1 ) and the seg- 



*-The first eight bytes of a header or text 
prefix contain control information used 
only in main storage buffer handling. 
Therefore these bytes are not placed on the 
direct access device. 



ment to one of two types of queues: DASD 
destination queues or DASD process queues. 

Each DASD destination queue contains 
message segments that are to be transmitted 
via a certain line, or message segments 
that are to be transmitted to a certain 
terminal. A DASD process queue contains 
message segments that are to be routed to a 
message processing prcgram. 
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The receive group of the LPS can check 
the validity of the name of the originating 
terminal and the destination code before 
routing the message to a DASD process queue 
or to a DASD destination queue. Each type 
of queue is maintained on a direct access 
storage device,, and all such queues are 
regarded as one data set, the DASD message 
queues data set. 



Each DASD process queue is associated 
with a message processing program. Mes- 
sages requiring text processing should be 
routed to the DASD process queue associated 
with the message processing program that 
processes that type of message. The user 
controls this routing either via the mes- 
sage header (the destination code is the 
name of the DASD process queue) or by LPS 
macro instructions that direct messages of 
a particular type to a particular queue. 
In Figure 5, step 2 shows the LPS routing a 
message to a DASD process queue. The 
receive group of the LPS can place messages 
that do not require text processing (e.g., 
.switched messag es) directly on the appro- 
priate DASD destination queues . 

For each DASD process queue, QTAM main- 
tains a corresponding queue in main 
storage. Each main storage (MS) process 
queue is maintained in buffers from the 
QTAM buffer pool defined in the message 
control program. The number of buffers 
allocated to a MS process queue is speci- 
fied in a data control block defined in the 
same message processing program. After the 
data control block for the MS process queue 
has been opened by the message processing 
program, a QTAM routine automatically 
passes the message segment from the DASD 
process queue to a buffer in the MS process 
queue (see step 3). In moving the prefix 
and segment to the buffer, the eight bytes 
that were deleted when the prefix and seg- 
ment were placed on the DASD process queue 
are restored, so that the prefix length is 
again 32 (header prefix) or 22 (text 
prefix) . 

Each time the message processing program 
gains control and issues a GET (step 4), 
QTAM passes message data froir the MS pro- 
cess queue to a user-specified work area in 
the message processing program. Message 
data is provided in the work unit specified 
by the user in the data control block. The 
work unit may be a complete iressage, a mes- 
sage segment, or a record. Before moving 
the message data to the work area, QTAM 
strips the header and text prefixes from 
the message segments, and places a 4-byte 
prefix in the first four bytes cf the work 
area. This prefix indicates the size and 
type of work unit on which the processing 
program is to operate. After receiving the 
message data, the message processing pro- 



gram processes it as required by the 
application. 

A message processing program generating 
a response message must define and open a 
data control block (DCB) governing message 
transfer before attempting to place the 
message on a DASD destination queue. This 
data control block contains information 
needed by QTAM to establish an MS destina- 
tion queue. When a PUT macro instruction 
is issued by a message processing program 
(step 5) , QTAM moves the message data from 
the user-specified work area into this MS 
destination queue. The header or text pre- 
fixes are attached to the message segments 
in the buffer areas that make up the MS 
destination queue,, As the message data 
fills the buffers, QTAM inserts chaining 
addresses and other necessary control 
information into the prefix fields. The 
response message generated by a message 
processing program can be of any size (the 
one shown in Figure 5 is 120 characters). 

After the header or text prefixes have 
been added in the MS destination queue, 
QTAM places the segment into the appropri- 
ate DASD destination queue on the DASD mes- 
sage queues data set (step 6). 

QTAM retrieves message segments from the 
DASD destination queues on a first- in 
first-out (FIFO) basis within priority 
groups. The message segments are brought 
in from the direct access device and placed 
in available buffers (step 7). The send 
group of the LPS then performs such user- 
selected functions as: converting the code 
of the message to the transmission code of 
the terminal, incorporating time-sent and 
date-sent information in the header, mes- 
sage logging,, and updating of message 
counts. These operations are performed in 
the buffers that receive the message seg- 
ments from the direct access device. QTAM 
then strips the header and text prefixes 
from the message segments and transmits the 
message to the appropriate terminal (step 
8). 

The header and text prefixes described 
in this section are generated automatically 
and used by QTAM routines. No programming 
considerations are required by the user for 
the manipulation of the buffers and their 
prefixes as messages flow through the 
system. 
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the header and text prefixes are shown in 
Appendix A. 



Calls From the Computer to an IBM 2740 
Model 2 



The IBM 2740 Model 2 is a single message 
block terminal. If the checking feature is 
installed, the terminal expects to receive 
an EOB at the end of the message block 
transmission. The terminal then sends a 
positive response to the Transmission Con- 
trol Unit and resets the terminal buffer 
address register to zero. The terminal 
then expects to receive an EOT, which 
initiates printing. Therefore, if a multi- 
block message is sent to the terminal, only 
the last block is printed and no error con- 
dition is returned. 

If a message sent to the IBM 2740 Model 
2 exceeds the v size of the terminal buffer, 
the terminal returns an EOT response indi- 
cating a buffer overflow condition. The 
transmitted message is not printed at the 
terminal and an error message indicating 
Unit Exception appears on the IBM 1052 
Printer-Keyboard, or at the operator control 
terminal. The error half word for the line 
has the "should not occur" bit set on, 

In order to avoid the situation in which 
the terminal is addressed during printing 
of a previous message,, a time delay is 
entered at the end of a message transmitted 
to an IBM 2740 Model 2. The length of the 
delay depends on the buffer size of the 
terminal: the delay is 8 seconds for a 
120-character buffer, 15 seconds for a 220- 
character buffer, and 30 seconds for a 440r 
character buffer. Messages sent during the 
delay are transmitted to the terminal at 
the expiration of the delay. 



MANAGEMENT OF SWITCHED LINES 



Insofar as possible, QTAM management of 
switched lines parallels the management of 
nonswitched lines. A number of differences 
should r>e understood, however. 

In a switched network, terminals are not 
attached to the computer by specific lines. 
Rather a line connection between the com- 
puter and a terminal is established over 
any available access line included in the 
line group. An available line is a line 
over which message traffic is not currently 
in progress, 

The management of switched lines by QTAM 
allows all current message traffic (both 



from CPU to terminal and from terminal to 
CPU) to be transmitted during one call. 
That is, once a line connection is estab- 
lished by either party, all messages queued 
for sending to the terminal are sent, and 
the terminal is allowed to send to the com- 
puter all messages it may have ready. The 
priority scheme implemented for switched 
lines is similar to the sending priority 
later described for nonswitched lines. 
That is., each time a message is received 
from a terminal, any messages on the 
destination queue for the terminal are -sent 
before accepting another message from the 
terminal. This is true regardless of 
whether the line connection is caused by a 
computer initiated call or by a terminal 
initiated call. The primary reason for 
handling switched lines in this manner 
(rather than requiring separate calls for 
incoming and outgoing messages) is in the 
interest of economy since the rates for a 
switched network are frequently on a per 
call basis, 



CALLS FROM THE COMPUTER TO A TERMINAL ON A 
SWITCHED LINE 



The Auto Call feature is required for com- 
puter initiated calls to a terminal on a 
switched network. This discussion assumes 
that this feature is included and that 
computer- initiated calls are desired. 

When messages appear on a destination 
queue for any type of terminal on a 
switched network,, the computer first deter- 
mines if the destination terminal is con- 
nected. If the terminal is connected, the 
message is scheduled for transmission using 
the existing connection. If the terminal 
is not connected, the computer attempts to 
find an available access line starting with 
the relative line defined in the terminal 
table entry for that terminal, If that 
access line is busy and additional lines 
are defined in the line group,, the computer 
attempts to initiate the call using one of 
those lines whose relative line number is 
greater than that defined for the terminal. 
If all the defined lines are busy, the 
attempt to call the terminal is deferred 
until a line becomes available. When an 
available access line is found,, the com- 
puter disables the line and dials the ter- 
minal using the dial digits specified in 
the terminal table entry. If the dialing 
procedure is completed successfully and if 
the terminal is ready to receive,, the 
queued messages are sent. (If the dialing 
procedure is not completed or if the com- 
puter receives a negative response to ad- 
dressing* the messages are not sent unless 
the user includes INTERCPT and RELEASEM 
macro instructions to cause later sending 
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of the messages. See the descriptions of 
these macro instructions . ) 

After all messages are sent to the ter- 
minal, the computer turns the line around 
and accepts any incoming messages the ter- 
minal may be ready to send. If more mes- 
sages arrive on the destination queue for 
the terminal while the computer is accept- 
ing an incoming message, those messages are 
sent to the terminal before another message 
is accepted from the terminal. When the 
last incoming message is received and no 
more messages appear on the destination 
queue,, the computer breaks the line connec- 
tion. It then reenables the line,, making 
that line available again. 



/CO Calls From the Computer to a Switched IBM 
CK 1050 



After the computer establishes contact with 
an IBM 1050 on a switched line, QTAM sends 
the addressing characters specified in the 
terminal table entry for that terminal,. 
When the terminal returns a positive 
response, QTAM sends all the messages in 
the queue for that terminal. QTAM then 
sends the polling characters specified in 
the polling list for that line and accepts 
an incoming message from the terminal if it 
has one ready. 

By turning the line around in this man- 
ner, QTAM allows the terminal to send dur- 
ing this connection all messages it may 
have ready. After each incoiring message 
terminated by an EOT (not to be confused 
with the EOT in a null message, which is 
described below) , QTAM sends any other mes- 
sages that may have arrived on the destina- 
tion queue for the terminal and then polls 
the terminal again,. The procedure of 
accepting a message from the terminal and 
then sending any messages that arrive on 
the destination queue continues until: 

1. The computer receives a negative 
response to the poll; or 

2. The terminal sends a null message. 
That is, a single EOT is sent follow- 
ing the positive response to the poll. 

QTAM recognizes either of these as an 
indication that the terminal has sent its 
last message (or has no message to send). 
Note that one terminal is being repeatedly 
polled instead of a list of terminals being 
polled in turn. 

After all incoming messages have been 
received from the terminal, QTAM makes a 
final check to determine if more messages 
have arrived on the destination queue for 



the terminal. If so, the procedures for 
sending the messages and then polling the 
terminal for incoming messages are repeated 
during this line connection. When no 
further messages have arrived on the 
destination queue, QTAM breaks the line 
connection and reenables the line for its 
next use. 



Calls From the Computer to a TWX Terminal 



T^ 



After the computer establishes contact with 
a TWX terminal by dialing its telephone 
number, the terminal sends its identifica- 
tion sequence. QTAM checks this sequence 
against the sequence specified in the ter- 
minal table entry for the terminal. If 
they do not match, QTAM sets the "message 
not sent" bit (bit 12) in the error half- 
word for the line to indicate an addressing 
error,, and breaks the line connection to 
the terminal (evidently, a wrong number was 
reached) . 

If the two sequences do match, QTAM 
sends all messages currently on the 
destination queue for that terminal, then 
sends the CPU identification sequence 
(defined in the polling list for that line) 
to the terminal. The terminal then sends 
to the computer any messages it may have 
ready. Each of these messages should end , 
with a transmitter off (X-off) character. ^fc 
Each time a message terminated by this 
character is received,, any further messages 
that have arrived on the destination queue 
for the terminal are sent. After these 
messages are sent (or if no further mes- 
sages have arrived on the destination 
queue) , QTAM again sends the CPU identifi- 
cation sequence and receives another mes- 
sage from the terminal. When the terminal 
has sent its last message,, it should send 
an X-off character in response to the CPU 
identification sequence. When this 
character is the only character received 
from the terminal after sending the CPU 
identification sequence, QTAM recognizes it 
as an indication that the terminal has no 
more messages to send. QTAM then makes a 
final check to determine if more messages 
have arrived on the destination queue for 
the terminal. If so, the procedures for 
sending these messages and then accepting 
incoming messages are repeated during this 
line connection. If the X-off character is 
not sent when there are no messages to 
send, the terminal will time-out,. It is 
therefore recommended tftaTf~ncT"error mes- 
sages be sent for a time-out indication,, 
because this will cause a repoll, time-out, 
and message sequence to be continually 
repeated.. When no further messages have 
arrived on the destination queue*, QTAM 
breaks the connection and reenables the 
line for its next use. 
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RESTRICTION : There is a possibility that 
some message on the destination queue for a 
TWX terminal will not be sent if the line 
connection between the computer and the 
terminal is terminated by the computer. To 
avoid this possibility, an EOT (or any 
other character that causes the connection 
to be broken prematurely) should not be 
sent by the terminal nor appear in a mes- 
sage being sent to the TWX terminal. 



CALLS FROM A SWITCHED TERMINAL TO THE 
COMPUTER 



When QTAM is not sending messages to or 
receiving messages from a switched terminal 
over a particular access line,, that line is 
enabled to permit switched terminals to 
call the computer. A terminal that wishes 
to send a message causes a line connection 
to be established by dialing the computer 
over an enabled line. After answering the 
call, QTAM receives the first incoming mes- 
sage from the terminal and then sends any 
messages on the destination queue for the 
terminal. From this point, the transmis- 
sion of further messages between the termi- 
nal and the CPU proceed in the same 
sequence described for computer-initiated 
calls. When the terminal indicates that it 
has no more messages, and no further mes- 
sages appear on the destination queue for 
the terminal , QTAM breaks the line connec- 
tion and reenables the line. 

Except that the first message is sent by 
the terminal, the receiving and sending 
procedures for a call initiated from either 
an IBM 1050, IBM 27 40,, or a TWX terminal 
are identical to those described in Calls 
from the Computer to a Switched Terminal . 



RELATIVE PRIORITY OF RECEIVING VERSUS 
SENDING OPERATIONS 



Message traffic can proceed in only one 
direction at a time over each of the half- 
duplex lines that comprise a QTAM- 
controlled telecommunications network. 

The user has the option of specifying, 
for each line group made up of nonswitched 
lines,, one of three relative priorities of 
receiving versus sending operations on each 
line in the group. He may specify that 
receiving has priority over sending, the 
two have equal priority, or sending has 
priority over receiving. The significance 
of each of these options is as follows. 

If receiving has priority over sending,, 
polling of terminals and receipt of incom- 



ing message traffic proceed continuously 
except during the user-specified polling 
interval at the end of each polling pass. 
A polling pass is one complete cycle 
through a single polling list. Outgoing 
messages, (if any are present on the 
destination queue for the terminal or 
line),, are sent only during this interval, 
and only until the interval expires. Upon 
expiration of the interval, outgoing mes- 
sage transmission ends after the current 
message is sent, regardless of whether any 
messages still remain queued. Polling and 
incoming message transmission then resume. 
It is important to note that if no polling 
interval is specified, outgoing message 
transmission cannot occur. Assuming that 
the user specifies a polling interval, he 
must also make it long enough to accommo- 
date any expected density of outgoing mes- 
sage traffic. In other words,, too short an 
interval will cause outgoing messages to 
"back up" on the destination queue for that 
terminal or line. 

If receiving and sending have equal 
priority, polling and incoming message 
traffic proceed continuously until all ter- 
minals on the line have been polled (i.e.,, 
until the end of one polling pass). Then 
outgoing messages (if any are present on 
the destination queue for the terminal or 
line) are sent. Once outgoing message 
transmission begins,, it continues until all 
messages on the queue have been sent, 
regardless of whether the user has speci- 
fied a polling interval,. When the destina- 
tion queue is depleted* polling and incom- 
ing message traffic resume. Note that, in 
contrast to the case where receiving has 
priority, outgoing message transmission 
occurs whether or not a polling interval is 
specified and regardless of the length of 
the interval. 

If sending has priority over receiving,, 
outgoing messages (if any are present on 
the destination queue) are sent: 

1. Each time a negative response or time- 
out to polling is received from a 
terminal. 

2. Each time an EOT is received from a 
terminal, indicating that a complete 
message has been sent. 

Once outgoing message transmission begins, 
it continues until all messages on the 
queue have been sent. Note that when send- 
ing has priority, outgoing transmission can 
occur after each terminal is polled* rather 
than only after a complete polling pass. 

The significance of these options dif- 
fers for those lines polled under control 
of the Auto Poll feature. For such lines* 
if receiving has priority over sending. 
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messages can not be sent to a terminal over 
that line. These lines are for input only. 
If sending and receiving have equal priori- 
ty, the significance is the same as for 
nonswitched lines except that the polling 
interval may not be specified. If sending 
has priority over receiving, outgoing mes- 
sages (if any are present on the destina- 
tion queue) are sent: 

1. Each time a message ending in an EOT 
is received by a terminal, or 

2. At the end of the polling list. 



SWITCHED NETWORKS 



Switched networks do not employ the same 
scheme of receiving-sending priorities as 
the nonswitched networks. Terminals are 
not attached to specific lines in the com- 
puter. The computer establishes a line 
connection with a terminal over any avail- 
able access line. An available line is a 
line over which message traffic is not cur- 
rently in progress,, even though the line is 
enabled to receive incoming calls. When 
messages appear on the destination queue 
for a terminal, the computer finds an 
available line, disables it, dials the ter- 
minal,, and sends the queued messages. The 
computer then polls the terminal (or sends 
the CPU's identification sequence for TWX 
terminals) for any incoming iressages that 
may be ready; the terminal is repolled 
after each message. When the last message 
is received (i.e., after a negative 
response to polling or an EOT) , the com- 
puter breaks the line connection,. It then 
reenables the line, making that line avail- 
able again,. 

When a terminal has a message to send, 
it dials the computer over an enabled line. 
The computer then performs the same action 
as it does after it dials the terminal and 
sends the queued messages: it repeatedly 
polls the terminal until a negative 
response to polling or an EOT is received. 
Then, it breaks the line connection and 
reenables the line. 



MANAGEMENT OF WTTA LINES 



The name World Trade telegraph terminal 
(WTTA terminal) refers to any of various 
European teletypewriters using a start-stop 
5- level code with two shifts (letters shift 
and figures shift) to transfer data over 
leased point-to-point telegraph lines 
(referred to as WTTA lines) at 50,, 75,, or 
100 baud (bits per second) . The codes used 



are either the International Telegraph 
Alphabet No. 2 (referred to as ITA2) or the 
Figure Protected Code ZSC3 (referred to as 
ZSC3). These two codes are illustrated in 
Appendix G. 
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A message sent to a WTTA terminal (out- 
put message) or sent by a WTTA terminal 
(input message) must always start with 
twelve LTRS characters. For an input mes- 
sage, these twelve characters are sent by 
the terminal operator, but they do not 
enter main storage. For an output message, 
they are automatically sent by QTAM. 

Normally, the motor of a WTTA terminal 
is off and the first LTRS character sent or 
received by the terminal starts the motor. 
The motor needs 1.5 seconds to reach nomi- 
nal speed. During this interval^ the ter- 
minal cannot correctly send or receive a 
character. The motor stops when no 
character has been transmitted during a 
period of from 10 to 30 seconds. The ter- 
minal is said to be operating in Motor-Off 
mode. Optionally,, the terminal can be 
equipped with a heavy-duty motor which is 
never switched off; in this case,, the ter- 
minal is said to be operating in Motor-On 
mode. 

When a WTTA terminal is operating in 
Motor-off mode,, the MONDLY operand of the 
DCB macro instruction (refer to the section 
DCB Macro Instruction) enables the user to 
specify the number of Mark characters cor- 
responding to the 1.5-second interval men- 
tioned above. When QTAM builds a Write 
channel program, it recognizes the motor 
mode of the terminal (motor-on or motor- 
off) and generates a LTRS character (that 
can be followed by a user- specif ied number 
of Mark characters) that precedes the data 
to be sent over the WTTA line. 

Most WTTA terminals can be equipped with 
another optional feature called the Auto- 
matic Answerback unit. This feature 
enables a string of up to 20 identification 
characters, generated by a mechanical drum, 
to be sent over the WTTA line by either 
pressing the IAM key of the terminal or 
receiving the character FIGS D (combination 
no. 4 in figures shift) . For terminals 
connected to a 2703 control unit, the 
character string must be a multiple of four 
significant characters (i.e., excluding 
FIGS and LTRS). 
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The user can specify that receiving has 
priority over sending,, that sending has 
priority over receiving, or that the two 
have equal priority. If receiving has 
priority over sending, (or if the two have 
equal priority) , and if there is no traffic 
over the line, the corresponding Prepare 
command is interrupted and an output mes- 
sage is sent to the WTTA teririnal. If an 
input message is being received, the output 
message will be sent only after an EOT 
character has been received or after a 
time-out has occurred. If sending has 
priority over receiving, the same procedure 
is followed, except when an input message 
is being received; in this case, the output 
message will be sent as soon as an EOM or 
EOT character is received or a time-out 
occurs. 



If the first character of an input mes- 
sage is received at the same time as the 
computer sends a character to the terminal, 
contention occurs and is resolved as 
follows: 



If contention occurs during the 1.5 
second interval required by the termi- 
nal to reach nominal speed, the termi- 
nal is given priority. 



SYSTEM GENERATION CONSIDERATIONS 



To incorporate QTAM facilities into an 
operating system* the user must perform an 
operating system generation, as explained 
in the System Generation publication, Form 
C28-6554. 

In his system generation macro instruc- 
tions, the user specifies the line and ter- 
minal configuration of the telecommunica- 
tions system being supported^ and any 
optional features required. In addition, 
he specifies QTAM as an option in the 
ACSMETH operand of the DATAMGT macro 
instruction. Specifying QTAM causes: 

1. Modules for the SYS1.TELCMLIB library 
to be moved from the SYS1.MODLIB 
library (SYS1.TELCMLIB must be a pre- 
allocated data set) . 

2. Get,, Put, Open,, Close, and QTAM Imple- 
mentation modules to be transferred 
from the SYS1.M0DLIB library to the 
generated SYS1.SVCLIB. 

3. The QTAM control program (consisting 
of the SVC 65 (Qwait) and SVC 67 
(Qpost) module and associated rou- 
tines) to be incorporated into the 
Supervisor Nucleus. 



If contention occurs on a significant 
character of an output rressage, the 
computer is given priority. 



In each IODEVICE macro instruction that 
represents a line adapter for a switched 
line,, the FEATURE operand must specify: 



Either the CPU or the WTTA terminal can 
ask for the identification sequence of the 
other,. When an identification exchange is 
performed, the CPU sends its identification 
sequence to the terminal (IAM=YES must be 
specified in the DCB macro instruction) , 
and the terminal sends its identification 
sequence to the CPU (WRU=YES must be speci- 
fied in the DCB macro instruction) . An 
identification exchange can be performed 
during either: 

1. Receiving operations, each time the 

terminal operator sends the WRU signal 
to the CPU; or 



1. AUTOCALL (if the line is to be used 
for CPU-initiated transmission) . 

2. AUTOANSR (if the line is to be used 
for terminal- initiated transmission). 

3. AUTOCALL and AUTOANSR (if the line is 
to be used for either terminal- or 
CPU-initiated transmission) . 

If the message control program includes the 
DATESTMP„TIMESTMP„ polling interval,, or 
checkpoint /res tart facilities, the SUPRVSOR 
macro must include the TIMER=INTERVAL 
operand. 



2. Sending operations,, at the beginning 
of an output message (if the WRU macro 
instruction is in the Send Header sub- 
group of the LPS) or at the end of an 
output message (if the WRU macro 
instruction is in the End Send sub- 
group of the LPS) . 

When the CPU receives the terminal identi- 
fication sequence, QTAM compares this 
sequence with that specified in the TERM 
macro instruction (refer to the section on 
the TERM Macro Instruction). 



PREPARING AND ENTERING TELECOMMUNICATIONS 
JOBS 



The message control program and each mes- 
sage processing program must be assembled 
separately,, using the operating system 
macro facilities. Each resulting object 
program must then be linkage edited, using 
the SYS1.TELCMLIB library as the SYSLIB for 
inclusion of the macro- introduced routines. 
The load modules may be placed on any 
library such as the SYS1.J0BLIB library. 
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In order to execute a telecommunications The organization of a message control 

system containing processing programs, the program and the job control cards required 

message control job should first be loaded for executing the job are illustrated in 

into the highest priority partition. The Appendix C of this publication. Similar 

message processing jobs should then be information for message processing programs 

loaded into any of the other partitions. is provided in the publication QTAM Message 

Processing Program Services .. 
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TELECOMMUNICATIONS APPLICATIONS 



A telecommunications system operating under 
OS QTAM can be designed for a wide variety 
of applications including message switch- 
ing, data collection, collected data pro- 
cessing, inquiry processing, and system 
modification. Each of these is described 
briefly below. 



MESSAGE CONTROL APPLICATIONS 



Two applications particularly suited to 
handling by a message control program are 
message switching and data collection. 



MESSAGE SWITCHING 



Message switching can be accomplished 
entirely within the message control program 
except that a message processing program 
must be loaded and initiated to terminate 
the execution of the message control 
program. 

In a message switching application, 
remote terminals transmit messages to the 
central processing unit, which relays the 
messages to one or more other remote ter- 
minals. The application does net prevent a 
remote terminal from sending a message to 
be processed. QTAM places these messages 
on a DASD process queue for handling by a 
message processing program (either concur- 
rently or at a later time) . 

When an incoming message is to be 
switched, the LPS section of the message 
control program routes the message to the 
DASD destination queue for the terminal to 
which the message is to be forwarded. If 
desired, the LPS can place information such 
as the time and date of receipt in the mes- 
sage header. Validating the codes of the 
originating and destination terminals and 
checking the input sequence number in the 
header can also be performed. Before a 
message is transmitted to its destination, 
the LPS can record in the header the date 
and time the message is sent, and the num- 
ber of the message in relation to other 
messages sent to that terminal. The LPS 
can also log the segments sequentially on a 
storage device for subsequent reference by 
the user with a different access method. 



DATA COLLECTION 



Data collection, like message switching, 
can be accomplished entirely within the ^s 
message control program except that a mes- 1 
sage processing program must be loaded and,/ 
initiated to terminate the execution of the 
message control program. 

In a data collection application, remote 
terminals send data in the form of messages 
to the CPU,. The messages are accumulated 
and stored by the computer, and subsequent- 
ly processed as a batch. 

The message control program can accumu- 
late data in two ways : 

1. It stores the data on DASD process 
queues. 

2. It stores the data on any secondary 
storage medium.. 

If the first method is used, the mes- 
sages can be obtained at any time (immedi- 
ately or later) by a message processing 
program (see Processing Collected Data) . 
The messages are routed to DASD process 
queues in the same manner as any other mes- 
sages that have a message processing pro- 
gram as their destination. The messages 
remain on these DASD process queues until 
the activation of a message processing pro- 
gram that issues a series of GET macro 
instructions to obtain and process the 
messages. 

In the second method,, the LOGSEG macro 
instruction in the LPS section of the mes- 
sage control program causes the segments to 
be recorded sequentially on a secondary 
storage device selected by the user. An 
access method other than QTAM must be used 
to retrieve the messages for processing. 



MESSAGE PROCESSING APPLICATIONS 

A wide variety of telecommunications appli- 
cations can be processed by a message pro- 
cessing program. Two of these applications 
are: 

1. Processing collected data. 

2. Inquiry processing* 
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PROCESSING COLLECTED DATA 



The processing of collected data is the 
second part of a 2-step application; the 
first step is the actual collection of the 
data by a message control program (see the 
preceding section, Data Collection) . 

If messages are collected on a DASD pro- 
cess queue, they remain on the queue until 
a message processing program issues GET 
macro instructions to obtain and process 
them. The message processing program that 
processes the collected data can either: 

1. Operate concurrently with the collec- 
tion of the data by the message con- 
trol program,, or 

2. Be loaded and initiated at a later 
time (for example, to process data at 
the end of the day after all message 
traffic has ceased) . 

In the latter case,, if the user wishes 
to have QTAM retrieve the messages from the 
DASD process queue, the message control 
program must remain operational. If ter- 
mination of the message control program is 
desired so that its partition is available 
for another program, the message processing 
program must implement another access 
method to perform the input operations. 

If the data is collected on a user- 
selected secondary storage device by a 
LOGSEG macro instruction, the data must be 
obtained for processing by an access method 
other than QTAM. 



INQUIRY PROCESSING 



An inquiry application involves receiving 
messages from remote terminals (performed 
by the message control program) , processing 
the data contained in the messages (per- 
formed by the message processing program) , 
and sending replies to the originating ter- 
minals (message control program). The 
routine (s) called by the message processing 
program to process the messages need not 
reside in main storage. For example, in an 
inquiry processing application that 
requires processing of many different types 
of inquiries, it may not be economical to 



have all of the required processing rou- 
tines in main storage. The message pro- 
cessing program can contain an analysis 
routine that determines the type of message 
and causes the routine required to process 
it to be loaded from a library. 

An optional feature of the inquiry ap- 
plication is operation in a conversational 
mode. In this mode, a terminal transmit- 
ting a message into the system is held on 
the line by the message control program 
until the message processing program 
generates a response message for transmis- 
sion back to the inquiring terminal. The 
response message is transmitted immediate- 
ly. Conversational mode is specified 
through the CONVERSE operand of the MODE 
macro instruction in the LPS section of the 
message control program. Another optional 
function particularly suited for a high 
volume inquiry application is specified by 
the EXPEDITE operand cf the PROCESS macro 
instruction in the message control program. 
The EXPEDITE operand causes messages to be 
routed directly to the main storage process 
queue associated with the message process- 
ing program,, bypassing the normal intermed- 
iate step of placing the messages on a DASD 
process queue. Both cf these optional 
functions decrease the time required to 
return an answer to the inquiring terminal. 



QTAM SYSTEM MODIFICATION 



There are three methods for transferring 
input control messages to a message pro- 
cessing task to modify the system. This 
allows the message processing task to 
initiate QTAM control functions. 

1. A dedicated terminal on the site of 
the computer may be reserved for this 
purpose. 

2,. A dedicated partition may be reserved 
whose function is to issue WTOR, await 
operator messages., and then issue QTAM 
control macros. 

3.. A message processing task may be used 
to periodically process messages, 
request an interrupt at a specified 
time, and then "poll" the console 
operator for control messages with a 
WTOR. 
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MESSAGE CONTROL PROGRAM 



In every QTAM-controlled telecommunications 
system, there must be one message control 
program. It is executed as the highest- 
priority job. 



1, Data Set Definition. 



2. Control Information. 



Message control includes those functions 
that: 



3. Data Set Initialization and 
Activation. 



1. Govern the flow of messages between 
the computer and remote terminals. 

2. Prepare the messages for processing 
and route them to their destinations 
(other terminals or message processing 
programs) . 

3. Provide the user with statistical 
information relating to message 
traffic 

4. Provide the user with copies of mes- 
sages received from or sent to remote 
terminals. 

The message control program includes 
both device handling and message handling 
routines of QTAM. Messages arriving at the 
computer from terminals are coded in the 
transmission code of the particular termi- 
nal type. QTAM provides facilities to con- 
vert these transmission codes to the 
extended binary- coded decimal interchange 
code (EBCDIC) , which simplifies message 
analysis. Similarly, messages being sent 
from the computer to a terminal are con- 
verted from EBCDIC to the transmission code 
of the terminal. 

Messages received from terminals can be 
routed to one or more destinations. QTAM 
routines check the val idity of the destina- 
tion codes and place messages in DASD 
queues according to their destinations. 
From these DASD queues, the nessages are 
usually sent to their destinations on a 
first- in first-out basis. However, a mes- 
sage priority scheme may be included to 
expedite the handling of selected messages. 
Priority processing of messages is particu- 
larly useful in an application such as 
inquiry processing, which requires rapid 
response to inquiries.. 

To construct his message control pro- 
gram, the user must select, place in order, 
and assemble macro instructions provided by 
QTAM. There are four major sections in the 
message control program and each can be 
wholly defined by QTAM macro instructions. 
The four major sections, in the order in 
which they will be discussed, are: 



4. Line Procedure Specification. 

Data set definition and control informa- 
tion macro instructions generate the 
tables, lists, and buffer areas needed in 
the system. Initialization and activation 
macro instructions ready the system for 
operation. 

The line procedure specification (LPS) 
section is the heart of the message control 
program. It is here that the user speci- 
fies, through LPS macro instructions, the 
manner in which he wishes message traffic 
in his system to be handled. The LPS macro 
instructions establish the linkage to QTAM 
routines that perform the message code 
translating, editing, error checking, log- 
ging, and routing functions. The parame- 
ters used by these routines originate 
either in the message header or in the LPS 
macro instructions supplied by the user. 
The information specified in the data set 
definition and control information sections 
is also used by the LPS routines in per- 
forming their functions. There must be one 
LPS for each communication line group that 
requires different message handling 
functions. 



Note : The user must insure that the 
operating system subroutine error trace 
scheme can function. This may be done by 
making a SAVE macro the first instruction 
in the message control program and in each 
message processing program. For detailed 
information, see the IBM System/360 Operat- 
ing System: Supervisor and Data Management 
Services publication. Form C28-6646^. 



PARAMETER REGISTERS 



QTAM control routines use general registers 
1 and 2 as parameter registers, in contrast 
to the general operating system practice of 
using registers and 1 as parameter 
registers. 
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DATA SET DEFINITION 



A data set definition macro instruction 
must be specified for each data set 
referred to by the message control program. 
Four types of data sets are normally used: 

• Direct access message queues data set. 

• Checkpoint data set. 

• Communication line group data sets. 

• Message log data set. 



DIRECT ACCESS MESSAGE QUEUES DATA SET 



One direct access message queues data set 
is required. Message segments awaiting 
transmission to destination terminals,, and 
message segments awaiting processing by a 
message processing program are placed on 
queues on a direct access storage device 
(DASD) . To establish these queues (called 
DASD destination queues and DASD process 
queues, respectively),, one DCB macro 
instruction must be issued to define the 
data control block for the message queues 
data set. 

The DASD data set must first be allo- 
cated and then preformatted by writing 
dummy records on the entire data set. The 
records must have a fixed length equal to 
the size of a buffer minus 8 (as defined by 
the BUFFER macro instruction). This for- 
matting process is necessary only once when 
the disk is initialized, not each time the 
message control job is executed. The 
direct access method (DAM) or sequential 
access method (SAM) may be used to format 
this volume. The characteristics of this 
data set are: 

• Sequential organization. 

• Fixed length records (record format = 
F) . 

• Unblocked records. 

• No secondary track allocation. 

The DD statement associated with the 
direct access message queues data set must 
allot space for these queues on the direct 
access device used. The space allotted 
must accommodate any messages that go 
through the LPS, including messages placed 
on the queues by ROUTE,, DIRECT, ERRMSG, and 
REROUTE macro instructions. The space 
allotted must also hold any rressages placed 
on the queues by a message processing pro- 
gram issuing a PUT. 



COMMUNICATION LINE GROUP DATA SETS 



cation lines. One or more data sets of 
this type are required. The user must 
specify one DCB macro instruction to define 
a data control block for each liner group in 
the system. A line group can consist of 
any number of lines that have the following 
common characteristics: 

• All lines in the group are either 
switched or nonswitched, 

• Association with the same type of ter- 
minal devices (e.g.,, all the lines con- 
nect IBM 1050s to the system* or all 
the lines connect IBM 1030s to the sys- 
tem) . Each type cf IBM 2740 (types I 
through VIII) is considered a separate 
terminal type. 

• Requirement for the same number of buf- 
fers to be requested in advance for 
each transmission of data from a termi- 
nal to the computer,. 

• Operation under the same relative 
priority specification. 

• Use of the same polling interval. 

• All lines in the group either do or do 
not use Auto Poll. 



Two additional requirements are: 

1. The relative position of the device 
access area in a terminal table entry 
must be the same for all terminal 
table entries associated with the 
lines in the line group (see the sec- 
tion on The Terminal Table) . 

2. No line within the line group can be 
defined as part of another line group. 



MESSAGE LOG DATA SET 



A message log data set consists of messages 
that are stored and maintained sequentially 
on secondary storage for accounting pur- 
poses. Message logs can be produced as a 
by-product of normal message handling. For 
each message log required, the user must 
specify the appropriate DCB macro instruc- 
tion. The specific DCB used depends on the 
secondary storage iredium employed; magnetic 
tape is the medium generally used. 

In the DCB defining the log data set, 
the user should specify: 

• DSORG=PS to indicate a sequential 
access method. 



A communication line group data set con- 
sists of messages transmitted via communi- 



• MACRF=(PM) to indicate the PUT macro 
with move mode. 
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• RECFM=V to indicate variable records,. 

• BFTEK=S to indicate simple buffering. 

Note ; RECFM=V is restricted. The user 
must save and restore the first word of the 
buffer if V is to be used. It is better to 
use F or FB. 

Information for supplying other required 
parameters for the DCB may be found in the 
QSAM DCB section of the IBM System/360 
Operating System; Supervisor and Data 
Management Macro Instructions publication* 
Form C28-6647. 

The entire contents of the buffers 
beginning with byte 8 (MSEGSZE) will be 
recorded in the log device. (In addition 
to the buffer contents, the log device 
needs 4 bytes for the access method doing 
the logging. Thus,, the buffer size speci- 
fied in the log DCB should be 4 bytes less 
than the QTAM buffer size.) Appendix A 
illustrates the fields of both header seg- 
ments and text segments. The QTAM message 
control program employs the Queued Sequen- 
tial Access Method (QSAM) to record mes- 
sages on the log. 



CHECKPOINT DATA SET 



A checkpoint data set consists of check- 
point records that are maintained and 
stored on a direct access storage device 
(DASD) . A DCB macro instruction must be 
issued to define the data control block for 
the checkpoint data set. The DD statement 
associated with the checkpoint data set 
must allot space for these records on the 
direct access device used. 

In the DCB defining the checkpoint data 
set, the user must specify: 

• DSORG=CQ 

• MACRF=(G„P) 

• DDNAME=TPCHKPNT 



DATA SET DEFINITION MACRO INSTRUCTIONS 



DCB Macro Instruction 



One DCB macro instruction must be specified 
for the DASD message queues data set,, the 
checkpoint data set, and for each communi- 
cation line group data set. At assembly 



time, DCB causes the allocation of main 
storage for a data control block, Parame- 
ters based on the keyword operands speci- 
fied in the macro instruction are included 
in the data control block. This macro 
generates no executable code, 

r t t 1 

J Name | Operation | Operand | 

j. + + ., 

1 deb | DCB \ keyword operands | 

l x x j 

deb 

the name of the macro instruction; it 
is also the name of the data control 
block generated by the expansion of 
the macro instruction. The name must 
be specified and may be from one to 
eight nonblank characters. The first 
character must be numeric, 

keyword operands 

the operands that can be included. 
The operands are written with separat- 
ing commas . Operands for each type of 
data set are described in Figures 6, 
7, and 8. 

When a parameter can be provided by an 
alternate source, one or more symbols 
appear opposite the operand associated 
with that parameter. When there is no 
alternate source (i.e., the parameter 
must be specified by the operand) ^ no 
symbol is shown. The symbols have the 
following meanings: 

Symbol Meaning 

DD The value of the operand can 
be provided at execution time 
by the Data Definition (DD) 
card for the data set. 

PP The value of the operand can 
be provided by the user's 
problem program any time 
before the data control block 
exit at Open time. 

OE The value of the operand can 
be provided by the problem 
program any time up to and 
including the data control 
block exit at Open time. 

CE The value of the operand can 
be provided by the problem 
program any time up to and 
including the data control 
block exit at Close time. 
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Keyword | Alternate | 

Operand j Source j Value Description 

+ + 

DSORG=CQ | | CQ 

| j identifies the data set organization as that of the 

| | direct access message queue or the checkpoint for a mes- 

| | sage control program (Note 1) . 

j_ j. _ _ _ _ _ _ _ 


T T 

MACRF=(G,P) | | (G,P) 

| | specifies that access to the queue is to be gained with 
1 | the GET and PUT macro instructions (Note 1). 

+ + 

[DDNAME=ddname] |PP | ddname 

| j the name that appears in the DD statement associated 

| j with the direct access message queues data control block 

| | (The name may not be TPCHKPNT) (Note 2), 



J. J. J. ., 

Note 1 ; If this operand is omitted, the telecommunications job, when executed, is 
terminated. 

Note 2 ; If this operand is omitted, and the value is not provided through the alter- 
nate source, the telecommunications job, when executed, is terminated. 

L . J 

Figure 6. Keyword Operands for the Direct Access Message Queues DCB Macro Instruction 



T T 

Alternate 
Source 
4 



Keyword 
Operand 



Value Description 



DSORG=CQ 



CQ 



identifies the data set organization as that of either 
the direct access message queue or the checkpoint for a 
message control program. 



MACRF=(G,P) 



(G,P) 

specifies that access to the records is to be gained 
with the GET and PUT macro instructions. 



DDNAME= | | TPCHKPNT 

TPCHKPNT I I is the name that appears in the DD statement associated 

with the data control block and that distinguishes the 
checkpoint DCB from the DASD message queues DCB. 

L J. L . 

Figure 7. Keyword Operands for the Checkpoint DCB Macro Instruction 
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T T 

Alternate 
Source 



Keyword 
Operand 



Value Description 



DSORG=CX 



cx 



identifies the data set organization as that of a 
communication line group (Note 1). 



MACRF=(G ( ,P) 



(G,P) 

specifies that access to the line group is to be 
gained with a queued access method (Note 1) . 



[DDNAME=ddname] 



PP 



ddname 
the name that appears in the DD statement associated 
with the data control block (Note 2). 



CPOLL= ( r el exp-j. , ) 



relexpx 
is the name of the polling list for the first line in 
the line group. There must be one value (a polling 
list name) in the sublist for each line in the line 
group. Each polling list name must be identical to 
the name specified in the POLL macro instruction used 
to define the list for that line. If a line is used 
for output only, the name of a polling list with no 
terminal entries must be specified. Any number of 
output-only lines may refer to this name (Note 1) . 

Example: Assume this statement is used at system 
generation to define the communication lines: 



UNITNAME 



UNIT=(021„ 022,024, 025) 

NAME=GROUPONE 



(The line addresses must be specified in ascending 
order. ) Assume also the CPOLL parameter is written 

CPOLL= (POLLl.„OUTPUT2„POLL3, 0UTPUT4) 

then POLL1 corresponds to the communication line with 
relative line number 1* OUTPUT2 corresponds to the 
communication line with relative line number 2 and so 
on. Either of the two following schemes may be used 
to assign relative line numbers to the lines in the 
line group. 

1. //ddname DD UNIT=(GROUPONE„l) 

The relative line numbers are assigned to the 
lines in the same order as they appear in the 
UNIT keyword parameter in the above UNITNAME 
macro instruction. The "1" in the DD statement 
indicates that only the first line is to be allo- 
cated. In this scheme, the first line in the 
UNITNAME sublist, line 021, will be polled 
according to the polling list labeled POLL1. If 
"2" is specified, then the first two lines, 021 
and 022, are allocated and if 4 is stated, all 
four lines are allocated and will be polled 
according to the corresponding lists in the CPCLL 
statement. 



x If this operand is omitted, the telecommunications job, when executed, is terminated. 
2 If this operand is omitted, and no value is provided through an alternate source, the 
telecommunications job, when executed, is terminated. 

L 

Figure 8. Keyword Operands for the Communications Line Group DCB Macro Instruction 
(Part 1 of 6) 
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T T 

Alternate 
Source 



Keyword 
Operand 



Value Description 



//ddname 


DD 


UNIT=024 


// 


DD 


UNIT=0 22 


// 


DD 


UNIT=021 


// 


DD 


UNIT=025 



2. 



In this scheme,, the relative line numbers are 
assigned to the lines in the order they appear 
in the concatenated DD statements and all 
specified lines are allocated to the job. The 
first line specified,, line 024, will have 
relative line number 1, and will be polled 
according to the polling list labeled POLL1. 
Note that the lines need not be in ascending 
order, and that any line can be dynamically 
allocated by itself,, or in any combination. 
If the following statements were used, 

//ddname DD UNIT=024 
// DD UNIT=025 

then lines 024 and 025 would be the only ones 
polled and would be polled according to the 
polling lists labeled POLL1 and OUTPUT2. The 
UNITNAME macro instruction is not used to 
determine the relative line number in this 
case. 

QTAM allows for the capability to search for 
the most economical dial or WATS line. QTAM 
begins at the beginning of a dial list and 
searches upward until it finds a non-busy WATS or 
dial line. 

By placing WATS lines in the dial list such 
that the lowest area coverage lines are first, and 
increasing area coverage lines following, with 
ordinary dial lines last, QTAM will now search for 
the most economical line possible. For those mes- 
sages destined for locations beyond a given WATS . 
area coverage, QTAM may now be told where in the 
list to begin its search. This same technique in 
telling QTAM where to start in the list can be 
used to avoid saturating the shorter range WATS 
lines. 

Previously, QTAM upon finding all dial lines 
busy, would requeue the message and await dial-in 
from a given terminal before transmission. Cur- 
rent QTAM overcomes this restriction and elimi- 
nates the necessity for queue "priming" in order 
to initiate transmission of these messages. 



Figure 8.. Keyword Operands for the Communication Line Group DCB Macro Instruction 
(Part 2 of 6) 
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T T 

Alternate 
Source 



Keyword 
Operand 



Value Description 



BUFRQ= absexp"] 
BUFRQ=2 J 



OE, DD 



absexp 

is the number of buffers to be requested for each 
transmission of data from the terminal to the com- 
puter. The requests are made well in advance of 
the message transmission,, and actual assignment of 
all buffers after the first is made as they are 
needed. The "absexp" should be equal to or great- 
er than 2, and must not be greater than 255 or the 
number of buffers specified in the BUFFER macro 
instruction, which ever is less. The primary fac- 
tors to be considered in determining the value of 
"absexp" are: the line speed, the size of the 
buffer pool as compared with the average number of 
buffers that are active at any one time, the size 
of each buffer as compared with the average size 
of a transmitted message, and the total system 
loading. If no value is provided either through 
the DCB macro instruction or an alternate source, 
or if a value of less than 2 is specified, 2 is 
assumed- 

The following method of calculating BUFRQ for each 
line group may be used- Assume that the slowest- 
speed lines in the system have a value of one. 
Assign to each of the remaining line groups in the 
system a value whose ratio to one is the same as 
the ratio of that line group's speed to the slow- 
est line group's speed. The value of the BUFRQ 
operand for each line group is equal to the calcu- 
lated value plus one. 
Example: 

• Line Group A has the slowest lines, 60 charac- 
ters per second (cps). Its value is therefore 
1. BUFRQ= 1+1=2. 

• Line Group B has 120-cps lines; therefore, its 
value is 120 divided by 60 or 2. BUFRQ for 
this line group is therefore 2+1=3. 

• Line Group C has 150-cps lines; 150 divided by 
60 and rounded off is 3. BUFRQ =3+1=4. 

• Line Group D has 180-cps lines; 180 divided by 
60 is 3. BUFRQ =3+1=4. 



~+ 



[l£JTVL=absexp| 
INTVL=0 J 



CE, DD 



absexp 

the polling interval (that is, the number of 
seconds of intentional delay between passes 
through a polling list) for the lines in this line 
group. After all the terminals in a polling list 
for a given line have been polled (beginning to 
end), a delay equal to the number of seconds spec- 
ified in this operand occurs before polling is 
restarted at the beginning of the list. The 
"absexp" must not be greater than 255. If this 
operand is omitted, INTVL=0 is assumed. This 
operand must be omitted if the line group consists 
of switched lines, WTTA lines, or if the Auto Poll 
feature is used. 



Figure 8. Keyword Operands for the Communication Line Group DCB Macro Instruction 
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T T 

Alternate 
Source 



Keyword 
Operand 



br 



Value Description 



CPRI=R 
CPRI=E 
CPRI=S 



OE,, DD 



R, E, or S 

indicates the relative priority to be given to 
sending and receiving operations, as follows: 

R — Receiving has priority over sending. An output 
message is sent on a given line only during a 
polling interval. 

E — Receiving and sending have equal priority,. After 
each full polling sequence on a given line, all 
output messages queued for that line are 
transmitted. 

S — Sending has priority over receiving. For non- 
switched lines after QTAM polls a terminal on a 
line, the line is made available for outgoing mes- 
sages, and the next terminal is polled only when 
there are no output messages in the queue for that 
line. For Auto Poll lines, the line is made 
available for outgoing messages after a message 
ending in an EOT is received by a terminal on the 
line, or when the end of the polling list is 
reached. If this operand is omitted, and no value 
is provided through an alternate source,, CPRI=S is 
assumed. CPRI=S must be specified for IBM 2740 
Communications Terminals, Types I and VI. If the 
line group includes IBM 2740 Model 2 terminals, 
CPRI=S must be specified. 

For WTTA lines, the relative priority is as 
follows: 

R or E — 

output messages are sent when there is no traffic 
over the line, after an EOT character has been 
received,, or after a time-out has occurred. 

S — output messages are sent when there is no traffic 
over the line,, after an EOT or EOM character has 
been received,, or after a time-out has occurred. 

This operand must be omitted if this line group 
consists of switched lines. 



ACLOC parameter deleted,. 



CLPS= relexp 



OE 



relexp 

the symbolic address of the line procedure speci- 
fication for the line group represented by this 
DCB macro. It must be identical to the name spec- 
ified in the name field of the LPSTART macro 
instruction. 



[EXLST= relexp] 



PP 



relexp 

is the symbolic address of the exit list (see the 
IBM System/360 Operating System: Supervisor and 
Data Management Services publication). 



Figure 8. Keyword Operands for the Communication Line Group DCB Macro Instruction 
(Part 4 of 6) 



40 



Keyword 
Operand 



Alternate 
Source 



Value Description 



THRESH= (absexpa. , 
absexp 2jr absexp 3 ,, 
absexp^ ) 
THRESH=(255,10,, 



5,5) 



This operand the threshold values to be used in 
determining excessive number cf errors (both tem- 
porary and permanent) for a specified number of 
transmissions for each line of this line group. 



absexpj. 

is the threshold value for the number of transmis- 
sions; less than or equal to 255. If the number 
of transmissions on any line in this line group 
reaches this threshold before any of the error 
counters reach their thresholds, the four thresh- 
old counters for this line will be added to the 
four cumulative counters for this line and the 
threshold counters will be reset. 

absexp 2 

is the number of contention situations on WTTA 
lines or the threshold value for the number of 
data checks on other lines; the value specified 
must be less than or equal to 255. If the number 
of data checks on any line in this line group 
reaches this threshold before the number of trans- 
missions reaches its threshold value,, a message is 
provided, (to the 1052 system console or the tele- 
communication system control terminal if the OPCTL 
macro instruction is included) „ the four threshold 
counters for this line are added to the four cumu- 
lative counters for this line and the threshold 
counters will be reset. 

absexp 3 

is the threshold value for the number of interven- 
tion required errors less than or equal to 255. 
Same action is taken as in description of absexp 2 
above . 

absexp,, 

is the threshold value for the number of time-outs 
(except text time-outs) less than or equal to 255. 
Same action is taken as in description of absexp 2 
above. 

If this operand is omitted, the threshold values 
255,, 10, 5„ 5 will be assumed. 



[DEVD=WT] 



specifies that WTTA terminals are to be used and 
causes a 4-byte field to be generated in the DCB 
(DCB+16) . This field contains information on IAM 
and WFU feature, EOM and EOT, and the number of 
pad characters to be used. 



r MON=YES"| 
MON=NO 



YES 



specifies that each terminal in the line group is 
equipped with the Motor-On feature. If this 
operand is omitted, MON=NO is assumed. 



Figure 8, Keyword operands for the Communications Line Group DCB Macro Instruction 
(Part 5 of 6) 
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Keyword 
Operand 



Alternate 
Source 



Value Description 



MONDLY=integer 
M0NDLY=15 



integer 

specifies the number of Mark characters corre- 
sponding to a 1 . 5-second interval when the termi- 
nal is not equipped with the Motor-On feature. 
MONDLY-10 corresponds to 50 -baud service* MONDLY= 
15 corresponds to 75-baud service,, and MONDLY=20 
corresponds to 100-baud service.. When this 
operand is omitted or exceeds 20,, MONDLY=15 is 
assumed. 



[~IAM=YES~| 
[ lAM=NO J 



YES 



indicates that the terminal can ask for the com- 
puter identification sequence by sending FIGS D. 
If this operand is omitted, IAM=NO is assumed. 



f"wRU=YES~ 
1 WRU=NO 



YES 



specifies that by sending FIGS D, either the com- 
puter or the terminal can ask for the identifica- 
tion sequence of the other,. When WRU=YES is spec- 
ified, IAM=YES is assumed,. If this operand is 
omitted, WRU=NO is assumed. 



b=- 

EOM=WRU 



EOM=X'hh' 
EOM=X'hhlF' 



This operand identifies the end of a message. 
WRU 

specifies that the WRU signal (FIGS D) is the end- 
of-message signal. FIGS x is set as FIGS D in the 
adapter (see Note 1,.). 

X J hh ' 

specifies that FIGS x is used as the EOM signal, 
hh is the hexadecimal representation of FIGS x set 
in the adapter (see Note 1.). 

X'hhlF" 

specifies that FIGS y LTRS is used as the EON 
signal, where hh is the hexadecimal representation 
of FIGS y set in the adapter (See Note 1),. 

WRU is assumed if this operand is omitted. 



EOT=2EOM "1 
EOT=X'hhlF , J 



2EOM 

specifies that two consecutive EOM signals will be 
recognized by QTAM as end-of-transmission,, except 
when IAM=YES and EOM=WRU are specified. 

X'hhlF* 

specifies that FIGS y LTRS is used as the EOT 
signal (see Note 1), and consequently, EOM=X'hhlF' 
cannot be used for the EOM signal* 

Note: A time-out is also recognized as EOT. 



Note 1 ; In the above description of the EOM and 
EOT operands, x and y are the values assigned by 
the user and set in the adapter at the time of 
installation of the equipment. 



• Figure 8. Keyword Operands for the Communications Line Group DCB Macro Instruction 
(Part 6 of 6). 
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Examples : 

1. A OCB macro instruction that defines 
the parameters of a data control block 
representing a direct access message 
queues data set (Figure 6): 

r t t T 

I Name | Operation | Operand | 

j. + + ., 

| QUEUE | DCB | DDNAME=DASDMSGQ, | 

| J |DSORG=CQ,MACRF=(G,P) | 
L X X. J 



The IBM-provided lcgic that supports the 
message control program uses this control 
information in performing the message- 
handling functions specified by the user. 
Nacro instructions are provided that allow 
the user to define the terminal table, 
polling lists, and buffer areas in accor- 
dance with the requirements of his 
application. 



2. A DCB macro instruction that defines 
the parameters of a data control block 
representing a communication line 
group data set (Figure 8) : 



r t t 

| Name J Operation | Operand 
j. + + 



j GRP1 1 DCB 



I 

| DDNAME=LNGR0UP1 , DSORG=CX, j 
|CPOLL=(POLLINEl,POLLINE2), j 
|MACRF=(G,P),BUFRQ=3, j 
|CPRI=E,CLPS=LPS1 | 

± J 



3. A DCB macro instruction that defines 
the parameters of a data control block 
representing a checkpoint data set 
(Figure 7) : 

r t t 1 

J Name | Operation | Operand | 

|. + + .j 

| CKRES | DCB | DDNAME=TPCHKPNT, DSORG=CQ t j 
I j |MACRF=(G,P) j 

L J. J. j 



CONTROL INFORMATION 



In constructing the message control program 
for his telecommunications system, the user 
must provide certain control information. 
This data includes: 

• A terminal table that contains all of 
the terminal codes (polling and ad- 
dressing characters or dial informa- 
tion) as well as complete information 
about the terminals connected to the 
system. 

• A polling list for each communication 
line that specifies the sequence in 
which terminals on the line are to be 
polled. 

• Buffer specifications that define the 
maximum number of buffers for the QTAM 
buffer pool and the size of the message 
segments used in the system. 



TERMINAL TABLE 



A telecommunications system using QTAM 
requires one terminal table. At assembly 
time, control information macro instruc- 
tions are used to produce a terminal table 
tailored to the user's device configura- 
tions and options desired. The terminal 
table consists of a table control field 
defining the length of the table, and 
blocks of information about each terminal. 
Each such block is called a terminal table 
entry. The four types of entries are: 
single terminal, group code, distribution 
list, and process program. Each type of 
entry is described in the following para- 
graphs. (Refer to Appendix A for diagram). 



The size, structure, and contents of the 
terminal table are based on information 
provided by the user through the TERMTBL, 
OPTION, TERM, DLIST, and PROCESS macro 
instructions. TERMTBL is specified once 
and defines the limits of the table. TERM 
creates a single terminal or group code 
entry in the terminal table. OPTION names 
and allocates storage for any optional 
subfield(s) to be included in the user area 
of a terminal table entry. The optional 
subfield(s) can contain information needed 
to perform various optional functions pro- 
vided by QTAM (subsequently discussed) or 
the user. The initial contents of each 
subfield are specified by the TERM macro 
instruction that defines the entry. DLIST 
defines a distribution list entry, and 
PROCESS creates a process program entry. 
Each entry in the terminal table begins on 
a fullword boundary. 

All alphabetic information in the termi- 
nal table is assembled as uppercase 
characters. 

QTAM provides a DSECT that enables the 
user to refer symbolically to the various 
terminal table fields (as explained under 
the TERMTBL macro instruction description) . 
All DSECTs are supplied on a private macro 
library and must be included in the message 
control program by the user. 
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Single Terminal Entry 



The terminal table must contain a single 
terminal entry for each terminal that can 
only send, only receive, or both send and 
receive messages (except for a terminal in 
a group code entry, discussed in the fol- 
lowing text) . If a terminal component is 
individually polled or addressed, the com- 
ponent must have a separate single terminal 
entry. 

Each single terminal entry contains a 
minimum of seven fields- The names of the 
first six fields are provided in a private 
dummy section, which can be included by 
specifying TERMTBLD. No parameters are 
required in this macro. The first five 
fields in each entry are of standard length 
and are described as follows: 

Field Description 

TNTRYSZE Size of the entry. 

TQCBADDR Address of the queue control 

block for the DASD destination 
queue associated with the 
terminal. 

TSEQUIN Sequence number for messages 
incoming from this terminal. 

TSEQOUT Sequence number for messages 
outgoing to this terminal. 

TSTATUS Status information indicating 
whether messages to the termi- 
nal are to be suppressed, 
whether messages can be sent 
to the terminal, and whether 
messages can be received from 
the terminal. 

The sixth field (TERMID) , containing the 
name assigned to the terminal by the user, 
appears in each single terminal entry. 
This name can also appear in the source or 
destination code field of the message head- 
er. The length of this field is the same 
in each entry and is based on information 
provided by the user. If the number of 
characters in each terminal name varies, 
the numoer of bytes in this field is equiv- 
alent to the number of characters in the 
longest terminal name. The user must spec- 
ify this number in the TERMTBL macro 
instruction. If the number of characters 
in each terminal name does not vary, the 
number of bytes in this field is equivalent 
to the fixed number of characters. The 
TERMID field length can be a maximum of 
eight bytes. 

Inclusion of the seventh field is 
optional. This field, called the user 
area, can contain one or more optional sub- 



fields. The name,, length, and boundary 
alignment of each such subfield,, if any,, 
are specified by an OPTION macro instruc- 
tion. The data content of the subfields is 
specified by TERM macros. Optional macro 
instructions such as COUNTER,, DIRECT, 
ERRMSG, INTERCPT, POLLIMIT, and REROUTE 
introduce routines that either obtain 
information from or place information into 
these subfields in order to perform their 
functions. The user can also store infor- 
mation in this area. Each single terminal 
and each group code entry associated with 
the same line group must contain the same 
optional subfields. 

The eighth field, called the device 
access area f is required-, This area con- 
tains the polling and/or addressing charac- 
ters for the terminal and, if it is a 
switched terminal,, its telephone number and 
the number of dial digits. For WTTA ter- 
minals., this area contains the terminal 
identification sequence. The size of the 
area depends on the requirements for the 
particular device., This field immediately 
follows the TERMID field if no optional 
subfields are included in the user area. 
If optional subfields are included, the 
device access field follows the last sub- 
field. The total size of the terminal name 
area, optional user area, and device access 
area must not exceed 252 bytes. 

The TERM macro instruction provides the 
initial contents for all fields in the 
single terminal entry. Detailed informa- 
tion on this entry is contained in 
Appendix A. 



Group Code Entry 



The terminal name in a group code entry 
represents a prespecified group of ter- 
minals on a line with special equipment 
that provides the group code feature. The 
feature permits simultaneous transmission 
of a message to a group of terminals 
through the specification of a single set 
Of unique address characters. Several com- 
binations of prespecified terminals can be 
grouped for this purpose. Each group has a 
group terminal name and a corresponding 
group code entry in the terminal table, 

A group code entry is identical in 
structure with the single terminal entry. 
However, three fields are either not used 
or used in a different manner. QTAM incre- 
ments the sequence number for outgoing mes- 
sages (TSEQOUT field) by one when the group 
is simultaneously sent a message. If any 
terminal in the group is also represented 
by a single terminal entry, the output 
sequence number for that entry is not 
changed. ' 
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The sequence number for incoming mes- 
sages (TSEQUIN field in the single terminal 
entry) is not applicable to the group code 
entry because the terminal group cannot 
collectively send a message to the system. 
For the same reason, there are no polling 
characters in the device access area of the 
group code entry. The total size of the 
terminal name area, optional user area, and 
device access area cannot exceed 252 bytes. 



The TERM macro instruction provides the 
initial contents for all fields in the 
group code entry. Detailed information on 
this entry can be found in Appendix A,. 



The list of addresses of single terminal 
entries follows the fifth active field. 
This list contains, in each of its sub- 
fields (reladdr through reladdr n ) , a rela- 
tive address that locates the corresponding 
single terminal entry in the terminal 
table. These addresses are relative to the 
base address of the table. The high-order 
bit of the last subfield is 1, indicating 
the end of the distribution list entry. 
The total size of the distribution list 
name area and the list area cannot exceed 
243 bytes. 

The DLIST macro instruction provides the 
initial contents for all fields in the dis- 
tribution list entry. 



Distribution List Entry 



A distribution list entry contains a list 
of addresses v of single terminal entries. 
These addresses are grouped under the list 
name. When a message contains the list 
name as a destination code, QTAM sends the 
message via separate transmissions to all 
terminals indicated by the list. Each ter- 
minal on the list must have a corresponding 
single terminal entry in the terminal 
table. 

Each distribution list entry contains 
five active fields and the list area. The 
first four active fields in each entry are 
of standard length. A description of the 
five active fields follows: 

Field Description 

TNTRYSZE Size of the entry. 

TDSTRQCB Address of the queue control 
block for the distribution 
list queue. 

TLISTKEY An access key to the start of 
the list of addresses. 

TSTATUS Status information. This 

field functions in the same 
way as the corresponding field 
for a single terminal entry 
with the following exception: 
the "receive" bit in this 
field is never used because 
terminals in the list cannot 
collectively send a message to 
the system. 

TERMID Contains the distribution list 
name. This name serves the 
same purpose as the terminal 
name in a single terminal 
entry and is subject to the 
same* restrictions N 



Process Program Entry 



The terminal table must include one process 
program entry for each DASD process queue. 
A DASD process queue contains those message 
segments that are to be routed to a message 
processing program. 

The structure of this entry is the same 
as that of the single terminal entry, with 
the following exceptions: 

1. The TSEQUIN field used in the single 
terminal entry is not used for the 
process program entry. 

2» The "receive" bit in the TSTATUS field 
is not used for the process program 
entry. 

3. The TERMID field in the process pro- 
gram entry contains the name of a DASD 
process queue rather than a terminal 
name. 

4„ There is no optional area or device 
access area in the process program 
entry. 

The PROCESS macro instruction provides 
the initial contents for all fields in the 
process program entry. Detailed informa- 
tion on this entry can be found in Appendix 
A. 



Terminal Table (TERMTBL) Macro Instruction 



The TERMTBL macro instruction causes a 
table control field to be created for the 
terminal table and defines the length of 
the table. Two private DSECTs exist that 
provide for symbolic reference to control 
fields used by QTAM. One private DSECT, 
TERMTBLD, provides names for the fields in 
each terminal table entry. The other priv- 
ate DSECT,, LCBD, supplies names for the 
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fields in a line control block (LCB), QTAM 
maintains an LCB for each communication 
line attached to the system; each LCB con- 
tains control information about the line 
with which it is associated. 

One TERMTBL macro instruction is 
required, and it must precede all other 
macro instructions used in creating the 
terminal table. 



r t t 1 

| Name | Operation! Operand | 

,. + x < 

j | TERMTBL j entry [, (n) ] [,OPCTL=chars] j 
| | | [,CPINTV= integer 3 | 

| j | [,,CKPART= integer] j 

l x x . J 



entry 



the name of the last entry in the ter- 
minal table. 



(n) 



the number of characters in the long- 
est terminal name. This operand is 
not necessary if the lengths of all 
terminal names are the same. The 
maximum number of characters is eight 
since "symbol" in the TERM macro has a 
maximum of eight,. 

OPCTL=chars 

specifies the label on the OPCTL macro 
instruction. 

If this operand is included, the error 
diagnostic messages are sent to the 
telecommunications control terminal. 
If this operand is not included, the 
error diagnostic messages will be sent 
to the system console. 

If this operand is included,, the OPCTL 
macro instruction must also be 
specified. 

CPINTV=integer 

the number of 15 second intervals 
between checkpoints; "integer" must be 
a value from 1 to 60 . Each integer 
represents 15 seconds. 

CKPART=integ er 

the number of partitions that must 
issue a CKREQ macro before a check- 
point will be taken (see discussion of 
CKREQ macro in IBM System/360 Operat- 
ing System: QTAM Message Processing 
Program Services ) . This number may 
range from one to fifteen. If CPINTV 
is also stated, the CPINTV value will 
take precedence. 



Note: 



The name field must be left blank. 



TERMTBL is the name generated fcr the ter- 
minal table by the macro instruction 
expansion. 



Terminal Table Optional Field (OPTION) 
Macro Instruction 



At assembly time* the OPTION macro instruc- 
tion names and allocates a specified amount 
of main storage in selected single terminal 
and group code entries in the terminal 
table. The storage allocated constitutes 
the optional-area field of the entries. 
One OPTION macro instruction is required 
for each optional-area subfield desired. 
The order of the subfields within the 
optional area is determined by the order of 
the OPTION macro instructions. 

Data values inserted into each optional- 
area subfield are specified by the "opdata" 
operands of the TERM macro instruction that 
creates the entry. 

The OPTION macro instruction (s)„ if 
used, must immediately follow the TERMTBL 
macro instruction,. The relative order of 
the specified subfields must correspond to 
the order in which the contents for the 
subfields are specified in the TERM macro 
instructions. 

Six LPS macro instructions link to IBM- 
provided routines that use fields allocated 
by OPTION macros in performing their func- 
tions. These optional LPS macros are 
COUNTER, DIRECT, ERRMSG, INTERCPT,, 
POLLIMIT, and REROUTE. The functions pro- 
vided by these macro instructions are dis- 
cussed under the individual macro instruc- 
tion descriptions. User-written routines 
can also store information in a subfield 
defined by an OPTION macro. QTAM defines a 
dummy control section for the option field 
in the message control program for symbolic 
references to the OPTION fields. 

For switched lines and for lines polled 
with the Auto Poll feature, a SOURCE macro 
instruction must appear in the LPS preced- 
ing any references to fields specified by 
OPTION macros. Reference must not be made 
to the fields for source errors. 

r t t T 

1 Name | Operation j Operand | 

j. + x 1 

I j subfield j OPTION jtypelength j 

1 l x x J 

subfield 

the name of the optional-area 
subfield. 

typelength 

the type and length of the subfield in 
the standard assembler language format 
(e.g., H, CL8, AL3) . When the sub- 
field is used in conjunction with the 
DIRECT, ERRMSG, or REROUTE macro 
instruction, CLn must be specified 
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where n equals or exceeds the longest 
name of any terminal table entry. If 
used in conjuction with the COUNTER 
macro instruction, "typelength" should 
be specified as H since COUNTER 
requires a halfword field aligned on a 
halfword boundary to perform its func- 
tion. INTERCPT and POLLIMIT require 
3-iayte and 1-byte fields,, respective- 
ly. No boundary alignment is 
required, however, a type D (double- 
word) constant may not be used. 

Example : The following is an example of 
the use of the TERMTBL and OPTION macro 
instructions : 



r t t 

| Name | Operation | Operand 



h 



| | TERMTBL | KCHI 

I I I 

j POLLMT | OPTION j FL1 



I COUNT 



OPTION 



H 



| ALTNTERM | OPTION j CL4 

I I I 

| I NTERCPT | OPTION | XL3 

I -L JL 



._J 



TERMTBL defines KCHI as the terminal 
name in the last entry in the terminal 
table. The OPTION macro instructions 
allocate a 9 -byte optional area for single 
terminal and group code entries in the ter- 
minal table. The optional area consists of 
four suofields: 

• POLLMT contains one byte for decimal 
data to be used by the POLLIMIT macro, 

• COUNT contains a halfword for decimal 
data to be used by the COUNTER macro. 

• ALTNTERM contains four bytes for a 
character string to be used by the 
DIRECT macro. 

• INTERCPT contains three bytes for an 
address to be used by the INTERCPT 
macro. 

The halfword specification for the COUNT 
subfield causes the Assembler to perform 
boundary alignment. In this case, no ad- 
justment is necessary because the COUNT 
subfield already begins on a halfword 
boundary. 



Terminal Table Entry (TERM) Macro 
Instruction 



The TERM macro instruction causes a termi- 
nal name and associated terminal informa- 



tion to be included as an entry in the ter- 
minal table. If a single terminal or com- 
ponent is involved, TERM produces a single 
terminal entry. If a group of terminals 
having the group code feature is involved, 
TERM produces a group code entry. 



One TERM macro instruction is required 
for: 



1. Each terminal (bcth switched and non- 
switched) that can send,, receive,, or 
send and receive messages. 

2, Each grbup of nonswitched terminals 
equipped with the group code feature. 

Terminals can only receive messages under 
the group code feature; they cannot send 
them. Each terminal in the group that can 
also send messages must be represented by a 
single terminal entry. 

All TERM macros must be grouped togeth- 
er. If messages are to be queued by line 
rather than by teririnal, the individual 
TERM macros must be grouped by relative 
line number within this TERM coding 
section- 







| Name | Oper- J 


Operand | 


| | ation | 




j. + + 


i 


| symbol | TERM | 


qtype,, deb,, rln | 


1 1 1 


[., adchars] | 


1 1 1 


t (opdata, . . . )] | 


1 1 1 


",CALL=integer"J [,, lD=hexchars] j 
,CALL=NONE J | 


I I I 


I 1 1 


(120)- 




1 1 1 


W BUFSIZE= <220> 




1 1 1 


Uuo) 





symbol 

the terminal name containing one to 
eight nonblank characters; it must be 
specified,. This name can also appear 
in the source or destination code 
field of a message header. 



qtype 



specifies the type of message queuing, 
nip™ specifies that outgoing messages 
are to be queued by terminal; that is, 
all messages for a given terminal are 
sent before any messages for other 
terminals are sent. (This is econom- 
ically advantageous when the destina- 
tion terminal is on a switched line. ) 
The highest-priority message for the 
given terminal is sent first. "T" 
must be specified for switched ter- 
minals* and may be specified for non- 
switched terminals. 
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deb 



rln 



"L" specifies that outgoing messages 
are to be queued by communication 
line; messages for all terminals on 
the line are sent on a first-in first- 
out basis within priority groups,. If 
"L" is specified, all TERM macros for 
each line must be grouped together. 
"L"must be specified for terminals 
using the Auto Poll feature. 

the name of the data control block for 
the line group in which the terminal 
is included. 

the relative line number, within the 
group, of the access line over which 
the computer and the terminal communi- 
cate. For a switched terminal, any 
value up to the total number of lines 
in the group may be specified,. When 
the computer calls a terminal, it 
attempts to make the call using the 
line whose relative number is speci- 
fied. If that line is unavailable, 
the next highest numbered line is 
examined, and so on until a free line 
is found. If all remaining lines in 
the line group are unavailable, the 
remote terminal is not dialed at this 
time. 



adchars 

the addressing and/or polling charac- 
ters for the terminal. The TERM macro 
expansion places these characters in 
the device access area of the terminal 
table entry. Refer to Figure 9 for 
the number and kind of characters to 
be specified for each type of terminal 
and line. The characters are speci- 
fied by writing the hexadecimal equiv- 
alent of the appropriate transmission 
code representation. In most systems 
the polling and addressing characters 
for the IBM 2260-2848 will be written 
just as they are given to the user by 
the customer engineer. This operand 

I must be omitted for TWX and WTTA ter- 
minals, and for IBM 2740 terminals, 
types I„ II, V, VI, VII and VIII. Its 
omission must be indicated by a comma. 
No polling characters are specified 
for a switched 1050 terminal. If 
polling is required for a switched 
1050 terminal, the polling characters 
are specified in a POLL macro 
instruction. 



2. If the polling characters of a non- 
switched IBM 1050 that is only to be 
polled (not addressed) are KO, 
"adchars" is written as xxxxC515, 
where "xxxx" represents the hexadeci- 
mal equivalent of any two characters 
(fill characters),. These two charac- 
ters will be ignored. 

3. If the addressing and polling charac- 
ters of a nonswitched IBM 1030 that is 
to be polled and addressed are K and 
L, "adchars" is written as 45xx4601 
where "xx" represents the hexadecimal 
equivalent of any character (fill 
character) . This character will be 
ignored. 

4,. If the same IBM 1030 is to be 

addressed only„ "adchars" would be 
written as C5. 

opdata 

the actual data to be inserted into 
the optional-area subfield(s) of the 
terminal table entry for this termi- 
nal. This operand allows flexibility 
because data can be specified for dif- 
ferent subfields depending on the 
optional functions required for mes- 
sages sent to or received from the 
terminal. However, all entries repre- 
senting terminals included in the same 
line group must have data specified 
for the same optional subfields. 
(Figure 10 shows an example of data 
specified for different subfields in 
entries not associated with the same 
line group.) The maximum length and 
type of data specified for each sub- 
field must correspond to the length 
and type specified by the OPTION macro 
instruction that allocates the addi- 
tional storage required for the sub- 
field. A comma is used to: 

1- Delimit the data for each 
subf ield, 

2. Indicate that no data is speci- 
fied for an intermediate 
subf ield. 

The user must specify either data or a 
comma for each subf ield specified by 
an OPTION macro. The framing charac- 
ters (X or C) and quotes are not 
coded* 



CALL 



Examples : 



If the addressing and polling charac- 
ters for a nonswitched IBM 1050 are R9 
and R0, "adchars" is written D213D215 
(D213 and D215 are the hexadecimal 
equivalents of the transmission code 
representation of R9 and R0) . 



is the telephone number of the termi- 
nal,. This operand must be specified 
for switched terminals only. NONE 
must be specified if the line(s) over 
which contact with the terminal is to 
be established does not have the Auto 
Call feature. NONE must be specified 
for WTTA terminals. 
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ID=hex chars 

the TWX terminal identification 
sequence for the TWX terminal repre- 
sented by the terminal table entry 
created by this TERM macro instruc- 
tion. This operand is specified only 
when the computer is to call TWX ter- 
minals. It is specified by writing 
the hexadecimal equivalent of the 8- 
level TWX code for the following 
characters : 



CR LF I, 



I n CR LF X-on 



where CR represents Carriage Return,, 
LF represents Line Feed, X-on repre- 
sents Transmitter On, and l x I 2 ... 
I n is a sequence of characters identi- 
fying the TWX terminal. When the com- 
puter calls the terminal,, the terminal 
automatically sends an identification 
sequence. 

For WTTA terminals,, this operand is 
specified only when WRU=YES is speci- 
fied in the DCB for the line,. This 
operand is specified by writing the 
hexidecimal equivalent of the 5-level 
code used by the terminal. The termi- 
nal sends its identification sequence 



each time the terminal sends the WRU 
signal. After the computer has 
received the identification sequence 
of a TWX or WTTA terminal, QTAM com- 
pares the sequence with the sequence 
specified by this operand, as a check 
that the intended terminal has in fact 
been reached. An equal compare per- 
mits message transmission to proceed. 
An unequal compare is treated as an 
addressing error; the message is not 
sent. 



BUFSIZE 

specifies the size of the buffer on 
the IBM 2740 Model 2 terminal. If 
this operand is emitted,, QTAM assumes 
that the terminal is not an IBM 2740 
Model 2. If an invalid buffer size is 
specified, BUFSIZE=440 is assumed. 



Examples : 

TWX ONE TERM T,DCB1, 1, , (1,0), 

CALL=51 08287317, ID=B15193. ,,. (etc) 

TTYA TERM T, DCBA,1, (0) , CALL=NONE, ID= 
02080C04 .... (etc) 



-T T" 

| Line Type | 



Terminal Type 



h 



Specify: 



IBM 1050, 1060, 

2260-2848 
ATfiT 83B3 
WU 11 5A 



Nonswitched 



4 



AAPP (if polling and addressing 

are required; for a 2260-2848 AA=PP) 

ffPP (if only polling is required) (See Note 1) 

AA (if only addressing is required) 



IBM 1030, 

2740 types 
III and IV 



Nonswitched 



AfPS (if polling and addressing are required) 



ffPS (if only polling is required) 

A (if only addressing is required) 



IBM 2740, types 
I and VI 



Nonswitched 



No polling or addressing characters are to be specified. 



IBM 1050 



Switched 



AA (if addressing is required) (See Ncte 2). 



IBM 2740, types 
II, V, VII, VIII 



Switched 



No polling or addressing characters 
are to be specified 



Legend; 



A = one addressing character 
P = one polling character 
f = one fill character 
S = one space character 

Note 1 : The second "P" must be specified as hexadecimal FF if a general poll of all 



2260s attached to a 2848 is desired. 

Note 2 : If polling is required, the polling characters are specified in a POLL macro 



instruction. 
Figure 9,. Addressing and Polling Characters for the TERM Macro Instruction 
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Here, the extra comma following the rela- 
tive line number indicates omission of the 
addressing and polling characters (which 
are not required for a TWX terminal) . 



Terminal Table List (DLIST) Macro 
Instruction 



The DLIST macro instruction causes the name 
of a list of terminals,, relative terminal 
table addresses of the entries for the ter- 
minals on the list,, and associated informa- 
tion on the list to be included as an entry 
in the terminal table. The list of termi- 
nals is called a distribution list, and the 
entry produced is a distribution list 
entry,. 



One DLIST macro instruction must be pro- 
vided for each such distribution list to be 
created. Terminals can only receive mes- 
sages through the distribution list trans- 
mission method (they cannot send messages). 



r t t 1 

| Name | Operation | Operand | 

l x + .j 

I | symbol ( DLIST | (entry ± , . . . ) | 

II x x J 



used. A message processing program,, like a 
terminal* can be a destination for a mes- 
sage- However,, unlike a terminal, the pro- 
cessing program is not associated with a 
communication line and does not need ad- 
dressing and polling characters. 

One PROCESS macro instruction must be 
included for each DASD process queue. 

The EXPEDITE operand permits the user to 
speed the processing cf messages by the 
message processing program associated with 
the process program entry. This function 
is valuable for an application such as 
inquiry processing, where rapid response to 
inquiries is required. 

r it r 1 

| Name J Operation | Operand | 

h x __ + .j 

| symbol | PROCESS [[EXPEDITE] j 

L X X J 



symbol 

the name of the process program entry 
in the terminal table. The name must 
be specified, and must be the same as 
the DDNAME specified in the MS process 
queue DCB macro instruction defined in 
a message processing program. The 
name can contain from one to eight 
nonblank characters. 



symbol 

the name of the list. This must be 
specified, and may be from one to 
eight nonblank characters. 

entry ±( , . . . 

the names of the terminals that are to 
be in the distribution list. 

Restriction : A name representing another 
distribution list must not be included as 
an operand of the DLIST macro instruction. 
All names in the list must be defined by 
either a TERM or a PROCESS macro instruc- 
tion. However,, no terminal table entry 
defined by a PROCESS macro specifying the 
EXPEDITE operand can be included in a dis- 
tribution list. 



Terminal Table Process (PROCESS) Macro 
Instruction 



The PROCESS macro instruction causes the 
name and associated information of a DASD 
process queue to be included as an entry in 
the terminal table. The entry produced is 
a process program entry. It differs from 
other terminal table entries in that it 
does not have an optional area or device 
access area, and the TSEQUIN field is not 



EXPEDITE 

specifies that message segments are to 
be routed directly to the message pro- 
cessing program's MS process queue,, 
thus bypassing the normal intermediate 
step of placing them on a DASD process 
queue. EXPEDITE should not be speci- 
fied if multisegment messages are 
expected,, because segments from dif- 
ferent messages may be intermixed as 
they are delivered to the queue. If 
EXPEDITE is specified, the MS process 
queue DCB must specify RECFM=S (see 
the OS QTAM Message Processing Program 
Services publication. The RETRIEVE 
macro instruction cannot be used to 
retrieve messages from a process queue 
when the EXPEDITE operand is used. 
Also,, the CANCELM-, EOA, EOBLC, ERRMSG , 
and REROUTE macros cannot be used for 
any message whose destination is a 
processing program queue identified by 
a terminal table entry defined by 
PROCESS EXPEDITE. 



Example — Terminal Table Definition 



Figure 10 shows a coding sequence used to 
create a terminal table. The terminals are 
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r t t t 

I No. J Name | Operation | Operand 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 



COUNT 

LIMIT 

DEST 

NYC 

BOS 

WAS 

PHI 

PIT 

RAL 

BOW 

CPU 



TERMTBL 

OPTION 

OPTION 

OPTION 

TERM 

TERM 

TERM 

TERM 

TERM 

TERM 

DLIST 

PROCESS 



CPU 

FL2 

FL1 

CL3 

L,GROUP1,,1,E407E40D, (0,8, BOW) 

L,,GROUP1,1,E207E20D„ (0*3, NYC) 

L, GROUP l. f 2,,E407E40D,, ( 0, 1,NYC) 

L„ GROUP2 , !, E407E40H, ( W „NYC) 

L„GROUP3,l,E407E40D, r (0) 

L„ GROUPS, 1, EU07E40D 

(BOS, WAS) 



Figure 10. Example: Coding Sequence for Creation of a Terminal Table 



IBM 1050s attached to the computer by non- 
switched lines. 



Instruction 1 (TERMTBL) : Identifies the 
last entry in the terminal table, Omission 
of the second operand indicates that all 
terminal names are of equal length,. 



Instructions 2 through 4 (OPTION) : Define 
the names and sizes of three optional-area 
subfields used for functions specified by 
the COUNTER, POLLIMIT,, and DIRECT macro 
instructions, respectively (refer to the 
section Line Procedure Specifications for a 
detailed discussion of the functions per- 
formed by these macro instructions). The 
single terminal entries in which these sub- 
fields are included and used depends on 
whether the optional functions are speci- 
fied in the LPS that handles the line group 
associated with the entry. 



Instructions 5 through 10 (TERM) : Define 
the single terminal entries for the termi- 
nals in four line groups, The operands of 
each TERM macro instruction provide infor- 
mation for the fields of the respective 
entries. In this example, outgoing mes- 
sages are queued by line; therefore, the 
first operand is an L in each case. 

The second operand of each TERM speci- 
fies the name of the data control block for 
the line group in which the terminal is 
included. In this case,, there are four 



line groups (therefore, 
blocks), 



four data control 



The third operand of each TERM is the 
relative line number cf the line to which 
the terminal is attached. The user estab- 
lishes the relative line number of each 
line at system generation via the IODEVICE 
macro. In the line group associated with 
the data control block named GROUP1, the 
New York and Boston terminals are attached 
to one line (relative line number 1) and 
the Washington terrrinal is attached to 
another line (relative line number 2). 
Since the messages are queued by line, the 
individual TERM macro instructions must be 
grouped by relative line number. For 
example,, it would be incorrect if the TERM 
macro instructions in this line group were 
in the order NYC, WAS, BOS. 

The fourth operand of each TERM contains 
the addressing and polling characters for 
the terminal. These characters are speci- 
fied in the hexadecimal equivalent of the 
transmission code. In instruction 5, E407 
is the hexadecimal equivalent of B3 and 
E40D is the hexadecimal equivalent of B6 in 
IBM 1050 code. B3 constitutes the address- 
ing characters; for IBM 1050s, the first 
addressing character identifies the termi- 
nal, and the second identifies the com- 
ponent (the number 3 indicates the com- 
ponent addressed is a card punch) . B6 con- 
stitutes the polling characters (6 is the 
identification of a card reader) . Transla- 
tion of the addressing-polling character 
representations in instruction 6 is A3A6; 
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translations of instructions 7 through 10 
are all B3B6. If all these terminals were 
on the same line, and all were to be 
addressed or polled individually, a unique 
set of addressing and polling characters 
would have to be assigned to each terminal. 

The fifth operand of each TERM contains 
the data to be inserted in the subfields 
defined by the OPTION macro instructions. 
Instructions 5 through 7 specify data for 
all three optional subfields because the 
LPS that operates on messages for this line 
group (GROUP1) includes the COUNTER,, 
POLLIMIT, and DIRECT macro instructions. 
COUNTER uses the COUNT subfield to keep a 
count of all messages received by the New 
York, Boston, and Washington terminals,, 
respectively. The count is set initially 
to zero in all entries,. 

POLLIMIT uses the value in the LIMIT 
subfield to restrict the number of messages 
that can be sent by a terminal during one 
polling pass; the New York (NYC), Boston 
(BOS) , and Washington (WAS) terminals can 
send a maximum of 8, 3, and 1 messages, 
respectively, during each polling pass. 
The DIRECT macro instruction uses the name 
specified in the DEST subfield to determine 
where to send the messages originated by 
each terminal. All messages sent by the 
New York terminal are directed to the Bos- 
ton and Washington terminals because the 
distribution list entry, BOW, is specified. 
Messages sent by the Boston and Washington 
terminals are directed to the New York 
terminal. 

Instruction 8 specifies data for only 
the COUNT and DEST subfields; a POLLIMIT 
macro instruction requiring information 
from the LIMIT subfield is not included in 
the LPS that operates on messages for this 
line group (GROUP2). It should be noted 
that an additional comma is required to 
specify that no data is inserted in the 
LIMIT subfield. Instruction 9 specifies 
data only for the COUNT subfield because 
neither the POLLIMIT nor DIRECT macro 
instruction is in the LPS for the line 
group (GROUP3) . In this case, no addition- 
al commas are required because no subfield 
following the COUNT subfield is used. 
Storage is not allocated for the LIMIT and 
DEST subfields in the terminal table entry 
for the Pittsburgh (PIT) terminal. 
Instruction 10 does not specify data for 
any of the optional subfields since none of 
the optional functions are specified in the 
LPS for the line group (GROUP4). No 
storage is allocated for the optional-area 
field in the entry for the Raleigh (RAD 
terminal. 

Instruction 11 (DLIST) : Creates a distri- 
bution list entry in the terminal table. 
When BOW (the name of the list) is found as 



a destination code in a message header,, or 
in the DEST subfield of the terminal send- 
ing the message, the message is routed to 
the Boston and Washington terminals. 

Instruction 12 (PROCESS) ; Creates a pro- 
cess program entry in the terminal table,. 
When CPU is specified as the destination 
code for a message, the message is routed 
to the message processing program repre- 
sented by this process program entry,. 



POLLING LISTS 



Polling is a centrally controlled method of 
permitting each terminal on a multi- 
terminal nonswitched line to send messages 
without contending for use of the line. 
QTAM contacts the terminals in the order 
established by a user-specified polling 
list. The polling list consists of control 
information followed by a series of point- 
ers to those terminal table entries repre- 
senting terminals to be polled. In opera- 
tion* QTAM steps through the pointers one 
by one. For each pointer QTAM finds the 
polling address in the indicated terminal 
table entry and sends that address on the 
line. As each terminal recognizes its 
unique address, it either sends a message 
if one is ready for transmission* or it 
sends a negative response if no message is 
ready. It should be noted that for a sys- 
tem without the Auto Poll feature, the 
negative response is handled by the QTAM 
system, thus requiring CPU time,. 

After a message is received from a ter- 
minal, the same terminal is again polled,, 
and it again sends a message if one is 
ready. This process is repeated until the 
terminal has no more messages to send or 
until the user-established polling limit 
for that terminal is reached* whichever 
occurs first. (The POLLIMIT macro instruc- 
tion is used to set the limit. ) 

Each time a negative response is 
received by the computer or the polling 
limit is reached, QTAM repeats the polling 
process using the next pointer in the list. 
This operation is repeated Until the termi- 
nal represented by the last pointer in the 
polling list has sent a negative response 
or has sent its last message,. When this 
occurs,, the polling process is rescheduled, 
starting at the beginning of the list. If 
the user has specified a polling interval 
in the DCB macro instruction for the line 
group, the next pass through the polling 
list is deferred for the time specified. 

A polling list must be specified for 
each line in the system. In defining a 
list for a nonswitched line,, the user may 
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enter terminal names as many times as he 
wants to, and in any order. A list can 
include terminals on one line only. If a 
line is used for output only, the user must 
specify a polling list with no terminal 
entries. 



The polling process has a different 
meaning for switched lines.. For non- 
switched lines, the computer generally 
initiates contact with the terminals,. 
However,, for switched lines,, the terminal 
normally initiates the contact. The poll- 
ing function in this case consists only of 
sending the polling address to the terminal 
that initiates the contact. The terminal 
responds by sending one or more messages. 
The polling address is sent by the computer 
after each message is received. The poll- 
ing list for a switched line does not con- 
tain pointers to terminal table entries. 
Rather,, it contains a single polling 
address (except for switched IBM 274,0 and 
TWX terminals) in addition to control 
information. When a terminal dials the 
telephone number associated with the line 
represented by this polling list, QTAM 
sends the polling address on the line, 



In the case of TWX terminals,, the poll- 
ing function consists of sending a charac- 
ter sequence on the line rather than a 
polling address. Otherwise,, the polling 
function is identical. In the case of 
switched IBM 2740s (types II,, V, VII,, and 
VIII), the polling list is specified as 
pollname POLL FFFF. Incoming message 
transmission begins when the computer an- 
swers a call from the terminal. 



To use QTAM more efficiently* the pro- 
grammer should be aware of the processing 
done by QTAM in polling. To poll -a termi- 
nal or line, QTAM forms a ring of buffer 
request blocks (for BRBs see section Buffer 
Definition and Use) with one associated 
buffer for each terminal in the polling 
list. There are three times when this ring 
is broken down by QTAM. 

1. On a negative response if sending has 
priority over receiving and there is a 
message to send. The ring is then 
rebuilt to send an outgoing message. 

2. At the end of a message transmission 
to free the buffers and the line for 
another transmission. 

3. At the end of a polling list to wait 
for the interval of time delay. 

Since this manipulation of the BRBs 
requires additional CPU time* the user must 
adjust the polling list to suit his appli- 
cation. To increase the performance,, the 
user may change the interval of time delay 
at certain periods of the day. Refer to 
Appendix O for an example of this 
capability, 

The POLL macro instruction is used to 
define polling lists for both switched and 
nonswitched lines. QTAM also provides rou- 
tines for examining and modifying polling 
lists. The macro instructions for imple- 
menting these routines are described in the 
section Examining and Modifying the Tele- 
communications System . The structure of 
polling lists is shown in Appendix A. 



For WTTA terminals, the polling function 
is not used because the message control 
program is always ready to receive input 
messages. However,, the polling list con- 
tains the computer identification sequence 
to be sent to a WTTA terminal each time an 
identification exchange is performed. 

The polling process has a different 
meaning for Auto Poll lines. Instead of 
causing a CPU interruption on receiving a 
negative response, as the regular poll 
does, the hardware itself initiates polling 
of the next terminal in the polling list. 
The polling list for an Auto Poll line does 
not contain pointers to terminal table 
entries. Rather, it contains (after open 
DASD time) a series of polling characters 
and index characters in addition to control 
information. When a message is read into a 
buffer, the index character,, associated 
with the polling characters of the respond- 
ing terminal , replaces the machine EOA 
character as the first data character in 
the header. (This index may be used to 
identify the responding terminal. ) 



Polling List Definition (POLL) Macro 
Instruction 



POLL generates a polling list for a specif- 
ic line attached to the telecommunications 
control unit (TCU) . For a nonswitched 
line, it defines the order in which termi- 
nals on the line. are to be polled. For a 
switched line, it specifies the polling 
address or identification sequence to be 
sent to any terminal that calls the com- 
puter on the line represented by the list. 
One POLL macro instruction must be written 
for each switched and each nonswitched line 
in the system. 



r t t 

| Name | Operation ] Operand 
j. + + 

pollname | POLL J ( ( entry, 

UAUTOPOL 

|/polladdr 
IVnid 
.1 



HlYl 



L JL 



J 
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pollname 

the name of the polling list to be 
created for the line. The name must 
be specified and must be identical 
with a name specified in the sublist 
of the CPOLL keyword operand in the 
DCB macro instruction for the line 
group. In addition, the polling list 
defined must be the list for the line 
indicated by the relative position of 
the name in the CPOLL sublist. 



entry, . . . 

the names of the terminals on a non- 
switched line or on an Auto Poll line 
in the order in which the terminals 
are to be polled. All the terminals 
specified must be on the same line. 
Each name specified must be the name 
of a TERM macro instruction defining a 
single terminal entry. If the line is 
used for output only, the . entry 
operands must be omitted. This 
operand is to be specified only for 
nonswitched lines and Auto Poll lines. 
This operand must be enclosed in 
parentheses even if only one terminal 

I name is specified. This operand must 
be omitted for WTTA lines. 



polladdr 

the polling address to be sent to any 
switched IBM terminal that dials the 
computer on the line represented by 
this polling list. All such terminals 
that can dial the computer on this 
line must recognize the same polling 
address. This operand must be speci- 
fied in the hexadecimal representation 
of the transmission code appropriate 
to the type of terminal on this line. 
This operand is to be specified only 
for switched lines on which IBM termi- 
nals can dial the computer. For a 
line on which an IBM 2740, type II, V, 
VII, or VIII can call the computer,, an 
operand of FFFF must be specified.. If 
the line is used for output only, this 
operand must be omitted. 



nid 



the number of characters in the iden- 
tification sequence of the computer to 
be sent to any TWX terminal that dials 
the computer on the line represented 
by this polling list, followed by the 
characters themselves. Both must be 
written as one continuous character 
string in hexadecimal notation. The 
ID characters must be written in hexa- 
decimal notation of 8-level TWX code. 
This operand is to be specified only 
for switched lines on which TWX termi- 
nals can call the computer. If the 
line is used for output only,, this 
operand must be omitted. 



For WTTA lines,, nid is the number of 
characters of the computer identifica- 
tion sequence, followed by the charac- 
ters themselves. Both must be written 
as one continuous character string in 
hexadecimal notation, that is, the 
number of characters is in hexadecimal 
notation, and the characters them- 
selves are in the hexadecimal repre- 
sentation of the 5-level code used by 
the terminal,. 

AUTOPOL 

Specifies that the terminals are on an 
Auto Poll line. 

"1" specifies that the terminals are 
IBM 1030 terminals. From 1 to 123 of 
these terminals may be specified for 
one line. 

"2" specifies that the terminals are 
either IBM 1050, 1060, 2740 Type III, 
or 2740 Type IV terminals. From 1 to 
8 2 of these terminals may be specified 
for one line- 



Example: The following POLL macro instruc- 
tions create the required polling lists for 
two nonswitched input lines,, one non- 
switched output line, one switched line on 
which IBM 1050s can dial the computer, two 
switched lines on which TWX terminals can 
dial the computer, one line polled using 
the Auto Poll feature, and one nonswitched 
WTTA line. 



1. 

2. 
3. 
4.. 
5, 

6,. 
7. 



"T T T 1 

| Name | Operation | Operand | 



POLLINEl|POLL 
POLLINE2JPOLL 
OUTLINE3JPOLL 
POLLINE4JPOLL 
POLLINE5JPOLL 

I 
POLLINE6JPOLL 
POLLINE7JPOLL 

1 
P0LLINE81P0LL 



(CHI, BOS) 

(NYC, PHI, NYC, WAS) 

E215 
0CB150FF72A3EB824 

BD2B15088 
03884DC9 

(NYC, PHI, NYC, WAS) , 
AUTOPOL=2 
08020830352D38122D 
0208 



These macro instructions create polling 
lists used to: 

1- Poll the Chicago and Boston terminals 
in that order. 

2. Poll the New York, Philadelphia, New 
York, and Washington terminals in that 
order. 

3. Represent the output-only line. 

4. Poll an IBM 1050 whose polling address 
is A0 (E215 is the 1050 transmission 
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code representation of AO, in hexadec- 
imal notation) . 

5. Send the computer's identification 
sequence,, preceded and followed by 
control characters, to any TWX termi- 
nal that calls the computer on this 
line. The operand for the next POLL 
macro is the transmission code repre- 
sentation Of CR LF DELETE NEWARK 
CR LF X-on, in hexadecimal notation. 
The X-on character will turn on the 
tape transmitter of the calling TWX. 

6. Send a "turnaround" sequence to any 
answering TWX that the CPU has dialed 
to turn on the tape transmitter of the 
TWX. The operand of this POLL macro 
instruction is the transmission code 
representation of X-on 2 X-off , in 
hexadecimal format. 

7. Auto Poll the terminals NYC, PHI,, NYC, 
WAS in that order.. Associate the 
index characters 1„ 2„ 3„ and 4 with 
their terminal entries. 

8. Send the computer identification 
sequence (preceded and followed by 
control characters) to any WTTA termi- 
nal with which an identification 
exchange is to be performed- The 
operand for this POLL macro instruc- 
tion is the device code representation 
of: 

10 CR LF 3 6 - 5 CR LF 

in hexadecimal notation. 



BUFFER DEFINITION AND USE 



1 



The user must specify the size and number 
of the main storage areas required by QTAM 
for input and output buffering. This 
information is specified by including one, 
and only one, BUFFER macro instruction in 
the message control program. These main 
storage areas collectively form a buffer 
pool that is allocated to and used dynamic- 
ally by QTAM to handle the transfer of mes- 
sage segments from and to all communication 
lines,, direct access queuing devices,, and 
processing queues. 

All buffers in the buffer pool have the 
same length. Since the entire header por- 
tion of a message must fit in the buffer 
that receives the first message segment,, 
the length specified must be equal to or 
greater than the size of the message header 
used, plus 32 (the size of the header pre- 
fix generated and used by QTAM routines). 



Buffer request blocks (BRBs) are QTAM 
control blocks used tc dynamically request 
buffers prior to their actual allocation 
from the buffer pool. The user should 
determine the number of BRBs required by 
the QTAM system. 

Management of data buffers for incoming 
and outgoing messages is an important fac- 
tor in running a QTAM system at optimal 
efficiency. There are three factors that a 
programmer must consider in weighing the 
balance between time and main storage. 

1,. The user must specify the correct 

number of buffers to assure no loss of 
or undue delay of data. 

2. The user must select the size of the 
buffer to accommodate his message. 

3. The user must decide on the number of 
BRBs needed for a reliable system- 
Figure 11 is provided to aid in deciding 

the effect of these factors. The figure 
shows the advantages in specifying more or 
less of the quantity with other considera- 
tions equal . 



Buffer Request Blocks 



The number of BRBs required in the system 
is a function of a number of variable fac- 
tors. The most important factor is the 
number of lines that are to be polled at 
the same time,. The user should initially 
specify a value that represents the maximum 
number of BRBs that cculd be in use,. If 
the user has specified a reasonable value 
in the BUFRQ operand of the DCB macro 
instruction for each communication line 
group,, the maximum number of BRBs he may 
need to specify in the BUFFER macro 
instruction may be calculated as follows: 

• For each line group* multiply the num- 
ber of buffers specified in the BUFRQ 
operand by the number of lines in the 
group; add the products obtained for 
each line group. To this figure, add 
the number of buffers specified in the 
BUFRQ operand of each concurrently used 
MS process queue. 

• To this figure „ add one buffer for each 
concurrently used MS destination queue 
defined by message processing programs. 
The sum is the maximum number of BRBs 
required. 

Example : Assume three line groups, GPONE, 
GPTWO, and GPTHREE, consisting of five, 
twelve,, and eight lines, respectively. The 
BUFRQ operands of GPONE„ GPTWO, and GPTHREE 
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QUANTITY 



ADVANTAGES 



larger buffers 



1. Requires fewer buffers for a message, resulting in less 
manipulation of the buffers by QTAM. 

2. Decreases the probability of losing data,, since there is 
less chance of missing a program controlled interrupt- 

3. Makes better use of disk tracks if buffers are filled. 

U. Decreases the disk time,, since there are fewer disk 
accesses. 



smaller buffers 



2. 



Requires a shorter amount of time to fill up buffers. This 
results in more dynamic use of main storage, and hence main 
storage is not tied up unprof itably . 

Increases likelihood of filling the entire buffer, therefore 
making better use of main storage,. If a message does not 
fill up the buffer (as in larger buffers), main storage is 
wasted,. 



more buffers 



1. Decreases the chance of losing data of incoming messages. 

2. Assures that outgoing messages are not delayed because they 
are waiting for a buffer. 

3. Allows more CPU time for other tasks,. 



fewer buffers 



1. Uses main storage more efficiently. No more buffers than 
the amount needed for incoming and outgoing messages are 
used, thus speeding throughput and saving main storage. 



more BRBs per line 



1. Reduces the chance of losing data due to a missed program 
controlled interrupt. 

2. Saves main storage if inactivity allows fewer buffers than 
BRBs to be specified. 



less BRBs per line 



1. Saves buffers. Since there are as many buffers used at one 
time, when transmitting or receiving on a line,, as there are 
BRBs assigned to the line; buffers are net unnecessarily 
tied up. (Only one buffer per line is assigned during 
polling.) 



Figure 11. Aids in Specifying BRBs and Buffers 



specify 3„ 3, and 5, respectively. Also 
assume that there is one message processing 
program that defines one MS process queue 
with BUFRQ=1, and one MS destination queue. 
The maximum number of BRBs to be specified 
in the BUFFER macro instruction is calcu- 
lated as (3x5) + (3x12) + (5x8) 
+ 1 + 1 = 93. 



the Auto Poll feature. In these cases the 
value derived above is the actual value 
that should be specified. In other cases 
experience within the operating environment 
of a particular application can best demon- 
strate the practicality of specifying a 
lesser number of BRBs. 



The value calculated using the above 
formula represents the maximum number of 
BRBs that could be needed at one time. In 
actual operation, the greatest number 
required at one time would be somewhat 
lower, and the user may wish to specify a 
lesser value. 

An exception arises when all the lines 
consist of dial lines or lines polled with 



Buffers 



The number of buffers specified must be 
equal to or greater than the number 
required at any one time. If the number of 
buffers needed to accommodate message 
traffic at any time exceeds the number of 
buffers available,, loss of message data can 
occur. Therefore, the user should specify 
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a sufficient number of buffers in the 
BUFFER macro instruction to prevent this 
problem from arising under any expected 
operating conditions. 

Because the actual number of buffers 
that will be in use at any particular 
moment depends on several variable factors, 
the user should initially specify a value 
that represents the maximum number that 
could be in use. 

This maximum value is related to the 
number of lines and the number of BRBs by 
the following formula: 

Number of buffers = L + f (BRB - L) 

where L = number of lines 

BRB = number of BRBs 

f = a factor with a value of 
between and 1. 

For small systems with few lines, the fac- 
tor f approaches one. For larger systems a 
value of 0.5 might be adequate. Experience 
within the operating environment of a par- 
ticular application can best demonstrate 
the appropriate value. 

Example : In the previous example there 
were 25 lines and 93 BRBs. A reasonable 
number of buffers for most applications 
would be 



25 + 0.5(93 - 25) 



number of buffers 
= 59. 



BUFFER Macro Instruction 



BUFFER specifies the main storage buffer 
areas required by QTAM. The buffers are 
allocated to QTAM as a block of main 
storage called the buffer pool. This macro 
instruction produces no executable code. 

r t t T 

I Name | Operation | Operand | 

|. x x ^ 

| | BUFFER | nnn, length [,, mmm] [, BRB] | 

L X X J 

nnn 

the number of buffers to be reserved 
(see the sample calculation in the 
preceding example) . 

length 

the length, in bytes, of each buffer. 
All buffers in the buffer pool have 
the same length. The length specified 
must equal or exceed the length of the 
longest message header used in the 
system (including any fields inserted 



mmm 



by the LPS)* plus 32 (the size of the 
QTAM-generated header prefix). The 
length of the message segment size 
used in the system is based on the 
buffer length. The minimum buffer 
length is 56 bytes (8 bytes if the 
Operator Control Facility is included) 
and the maximum is 278 bytes. The 
minimum does not include bytes 
reserved by the LPSTART macro for 
fields to be inserted into the header. 
For instance, if 7 bytes were reserved 
by LPSTART for the date, then the 
minimum buffer size would be 63 rather 
than 56. Length should be defined so 
that each buffer starts on a fullword 
boundary. The length of the records 
in the DASD message queues should be 8 
bytes less than the size specified in 
this parameter. 



the number of channel command words 
QTAM must generate for sending the 
idle characters specified by the PAUSE 
macro instructions in the LPS sections 
of the message control program. The 
number of CCWs required depends on a 
number of variables whose cumulative 
effect changes during system operation 
(The principal factors are the number 
of appearances in messages of each 
control character that requires inser- 
tion of characters, and the number of 
lines over which outgoing messages are 
being sent at the moment. ) Because 
determining the actual number of CCWs 
that could be needed at any given 
moment is impractical, the user should 
initially specify a "worst-case" 
value, (i.e., a value representing the 
maximum number of CCWs that could be 
required under any operating condi- 
tion), This value may be calculated 
as follows: 

mmm = 2(L X (I ± ) +L a (I a ) + *.» L n (I n )) 
where L = the number of lines in 
the line group and I = the 
expected number of appearances of 
control characters per outgoing 
message buffer for which inser- 
tion of idle characters is 
required; L(I) to be calculated 
for each of the line groups 1 
through n. 

Example : Assume that the LPS for the first 
line group includes PAUSE macro instruc- 
tions that cause insertion of idle charac- 
ters each time a NL (new line) or an HT 
(horizontal tab) character is encountered 
in an outgoing message buffer. Also assume 
that the expected number of appearances of 
these control characters is two, for the NL 
character, and six, for the HT character, 
la. is therefore 2+6=8. If the line 
group consists of five lines., L^da.) equals 
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5(8). If the system includes two other 
line groups for which L(I), calculated 
similarly, equals 3(6) and 7(5), then mmm = 
2(5(8) + 3(6) + 7(5)) = 186. 

In most applications this "worst-case" 
value will considerably exceed the actual 
number of CCWs required. Therefore, the 
user may reduce the value during system 
testing. If this operand is omitted,, zero 
is assumed. 

BRB= integer 

the number of buffer request blocks 
(BRBs) to be reserved. (See the 
sample calculation in a previous 
example,. ) This number must be greater 
than or equal to the number of buffers 
specified. If this operand is omitted 
or the number specified is less than 
the number of buffers, the number of 
BRBs is set equal to the number of 
buffers. 

Example ; Assume a system in which: 

1. 59 buffers of 100 bytes each are 
required. 

2 . The number of CCWs required for inser- 
tion of idle characters is calculated 
as in the preceding example. 

3. The number of BRBs required is 93. 

The BUFFER macro instruction would then be 
written: 

BUFFER 59,100,186,BRB=93 



DATA SET INITIALIZATION AND ACTIVATION 



The data set initialization and activation 
section of the message control program 
begins with an OPEN macro instruction and 
ends with the ENDREADY macro instruction. 
Within the message control program, this 
section must precede the LPS section. When 
the instructions in this section have been 
executed, the system is ready to handle 
message traffic. 

The OPEN macro instruction completes the 
initialization for and activation, of the 
DASD message queues data set,, communication 
line group data set, message-log data set, 
and checkpoint data set. The data sets 
used by the message control program can be 
opened by separate OPEN macro instructions, 
or they can all be opened with one OPEN. 
Regardless of which method is used,, the 
user must open the DASD message queues data 
set before any other data set used by QTAM. 
If the checkpoint option is used,, the 
checkpoint data set must be opened after 



the DASD message queues data set and before 
the line group data set. Opening a line 
group data set causes all lines in the line 
group to be prepared for operation; the 
lines are activated automatically for mes- 
sage reception- 
Activation of a line group data set can 
be deferred through use of the IDLE operand 
in the OPEN macro instruction. The purpose 
of such a deferral is to facilitate activa- 
tion of particular lines in a line group. 
This is accomplished by the STARTLN macro 
instruction (see the section Examining and 
Modifying the Telecommunications System),. 

There can be a 30-second delay for each 
OPEN macro instruction for line not opened 
idle- During Open time, QTAM must issue 
commands to prepare the lines for opera- 
tion. If the interrupt indicating the line 
is initialized has not been received. QTAM 
waits 30 seconds for completion. If the 
commands have not completed after 30 
seconds, the following message is written 
to the console . 

IEC80GI ENDING STATUS NOT RECEIVED FROM 
LINE XXX - LINE UNAVAILABLE 

Opening multiple data sets with one OPEN 
macro instruction may avoid the 30-second 
delay. 

The ENDREADY macro instruction must be 
the last instruction in the initialization 
and activation section. When ENDREADY has 
been executed, the system is ready to 
handle message traffic. The expansion of 
this macro instruction causes a branch to 
the IBM-provided logic that supports the 
message control program. The first message 
procured can be either a message coming in 
from a terminal, or a message being sent to 
a terminal by a message processing program. 
When the first message is procured, control 
is returned to the LPS section of the mes- 
sage control program for handling of the 
message- 
Once the LPS is initially entered via 
the expansion of the ENDREADY macro 
instruction, execution in the message con- 
trol program is restricted to the LPS sec- 
tion; that is,, the LPS is continually reen- 
tered to handle messages entering and leav- 
ing the computer as long as the message 
control program is active. 

The STARTLN,, COPYP, CHNGP,, COPYT, CHNGT , 
and COPYQ macro instructions may be used in 
the initialization and activation section 
of the message control program. This is 
useful if the user wishes to modify the 
status of his system at the time the mes- 
sage control program is initiated. For 
example, a COPYT macro instruction can be 
issued to record the system status prior to 
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opening the telecommunications line groups. 
If the above macro instructions are used in 
this section, they must precede the 
ENDREADY macro instruction. Generally,, 
however, these macros are employed in 
another program so that the status of the 
system can be dynamically examined and 
modified as needed. The section Examining 
and Modifying the Telecommunications System 
contains a detailed discussion of the 
macros that may be issued in a message con- 
trol program. Those which may be issued in 
a message processing program are described 
in the publication OS QTAM Message Pro- 
cessing program Services . 



OPEN Macro Instruction 



OPEN is used in the message control program 
to complete initialization and activation 
of the message-log, line group and DASD 
message queues data sets. All of these 
data sets can be opened separately or with 
one OPEN. However, the user must open the 
DASD message queues data set before any 
other data set used by QTAM. The operands 
of the OPEN macro instruction specify the 
names of the data control blocks for the 
data sets. A sublist for each data control 
block name specified is used to: 

1. Specify the nature of the data set 
(input, output, or both). 

2. Specify whether or not activation is 
to be deferred for communication line 
groups. 

If the data control block for a line 
group is specified, the OPEN routine com- 
pletes the initialization of all lines in 
the line group and automatically activates 
the lines for message transmission, unless 
the IDLE operand is specified in the sub- 
list. If in the OPEN for a nonswitched 
line group,, the user specifies INPUT or 
INOUT,, JDUt does not specify IDLE, the Open 
routine initiates polling on those lines in 
the group that have an active polling list 
with terminal entries,. If in the OPEN for 
a switched line group the user specifies 
INPUT or INOUT,, but does not specify IDLE,, 
the Open routine issues commands to enable 
each line in the line group. 

If IDLE is specified, all of the lines, 
or particular lines in the line group,, can 
be subsequently activated by one or more 
STARTLN macro instructions. The user can 
also inhibit polling or enabling of a line 
by changing the second byte of the polling 
list for that line to zero (this deacti- 
vates the polling list) before issuing the 
OPEN for the line group, but after issuing 
the OPEN for the direct access message 



queues. (See the CHNGP macro instruction 
description in the section Examining and 
Modifying the Telecommunications System. ) 

If this OPEN specifies a message-log 
data control block, the QTAM routines are 
brought into the system and prepared for 
placement of messages on the logging 
device. OUTPUT must be specified as the 
first operand in the sublist for the 
message-log data control block name. 



r T T 

] Name ] Op | Operand 



symbol ] OPEN | / 

] ](\dcb 1 , [( 



INPUT 

OUTPUT 

INOUT 



[,IDLE 



]>3 jl 



r.MF=L "J 

|_,,MF= (E, listname)J 



>l 



symbol 

either the name cf the first instruc- 
tion generated by the OPEN or the name 
of a parameter list created by OPEN. 
If the MF=L operand is specified, sym- 
bol must be included; it becomes the 
name of the parameter list. If no MF 
operand is specified, or the MF=(E„ 
listname) operand is specified* symbol 
is optional. If included,, it becomes 
the name of the first instruction 
generated by OPEN. 



dcbj. 



the address of the data control block 
to be opened. If register notation is 
used,, the register designated must 
contain the address of the data con- 
trol block. 

INPUT 

specifies an input data set. If 
neither INPUT* OUTPUT, nor INOUT is 
specified,, INPUT is assumed. Polling 
begins on all lines having an active 
polling list with terminal entries 
provided: (1) the data set being 
opened is for a nonswitched line 
group, (2) the INPUT (or INOUT) 
operand is specified (or INPUT is 
assumed), and (3) the IDLE operand is 
omitted. If the data set being opened 
is for a switched line group,, and con- 
ditions 2 and 3 apply,, then all lines 
in the line group are enabled. 

OUTPUT 

specifies an output data set. If the 
data set being opened is for a non- 
switched line group and OUTPUT is 
specified,, the CPOLL operand of the 
DCB macro for the line group refers to 
a polling list with no terminal 
entries,. OUTPUT only cannot be speci- 
fied for switched line groups. 
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INOUT 



IDLE 



specifies a data set that can be used 
for both input and output. If a line 
group data set is being opened, some of 
the lines can be used for input and 
others for output „ simultaneously. 



For nonswitched line groups: If an 
entry in the CPOLL operand sublist in 
the DCB macro for the line group 
points to a polling list with terminal 
entries, the line is a polled input 
line; polling begins if the polling 
list is active and the IDLE operand is 
not specified in the OPEN macro. If 
an entry in the CPOLL operand sublist 
in the DCB points to a polling list 
with no terminal entries,, the line is 
an output-only line. 



For switched line groups: If an entry 
in the CPOLL operand sublist in the 
DCB macro for the line group points to 
a polling list that contains a polling 
address (or CPU identification for 
TWX),, the line is an input line; it is 
enabled if the polling list is active 
and the IDLE operand is not specified 
in the OPEN macro. If an entry in the 
CPOLL operand sublist in the DCB 
points to a polling list without a 
polling address, the line is an output 
line,. 



pertains only to line group data sets. 
If the IDLE operand is included,, the 
line group data set is initialized but 
the lines remain inactive until acti- 
vated by a STARTLN macro instruction. 
If IDLE is omitted, all lines in the 
group are automatically activated when 
the OPEN is executed. 



MF= ( E„ 1 istname ) 

causes execution of the Open routine, 
using the parameter list referred to 
by listname , This list was created by 
a macro having the MF=L operand speci- 
fied,, as previously described. Param- 
eters specified through a macro having 
MF=(E» listname) operand override 
corresponding parameters in the list,. 
An OPEN macro with the MF=(E„ listname) 
operand can also refer to a parameter 
list created by a CLOSE macro with an 
MF=L operand. 

Examples : An OPEN macro instruction that 
could be used in the message control pro- 
gram is: 

r t t 1 

| Name | Op | Operand | 

, + + . .| 

J j OPEN j (QUEUE,, . GROUPONE, (INOUT. IDLE) , j 
j j j MSG LOG,, (OUTPUT)) j 

L X JL J 

In this example,, QUEUE is the name of the 
direct access message queues data set, 
GROUPONE is the name of a line group data 
set,, and MSGLOG is the name of the message- 
log data set. If the user wished to use 
the MF=L form, the macro would be written: 

r t t T 

I Name j Op ) Operand | 

y + + \ 

I OLST j OPEN | (QUEUE,, ,, GROUPONE* (INOUT. IDLE) , j 
| | j MSGLOG, (OUTPUT) ) W MF=L j 

t X X J 

The user would place the above macro among 
his definition statements so the parameter 
list would be produced among the constants. 
The following macro, placed in the data set 
initialization section, could be used to 
activate the data sets: 



Note: If neither INOUT nor IDLE is 
specified for a particular data set* 
and a subsequent data control block 
address is specified in the sublist, 
two commas must appear between the two 
specified data control block 
addresses . 



r t t 1 

| Name | Op J Operand | 

|. + x 1 

j j OPEN j (QUEUE. „ GROUPONE, (INOUT. IDLE) ,, j 
j | | MSGLOG. (OUTPUT) } . MF= (E. OLST) | 

L X -L J 



MF=L 



causes creation of a parameter list 
based on the OPEN operands. No 
executable code is generated. The 
user must specify this form of the 
OPEN with his program constants. The 
parameters in the list are not used 
until the problem program issues an 
OPEN (or CLOSE) macro with an MF=(E„ 
listname) operand referring to the 
list (see example below)- The name 
specified in the name field of the 
OPEN macro becomes the name assigned 
to the parameter list. 



ENDREADY Macro Instruction 



The data set initialization and activa- 
tion section must be ended by an ENDREADY 
macro instruction. ENDREADY is essentially 
a type of wait instruction. The event 
awaited is the procurement of the first 
message. Only one ENDREADY macro can be 
included, and it must be the last in the 
group of data set initialization and acti- 
vation instructions. 
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r t t 1 

| Name | Operation) Operand J 

V + x ., 

j |ENDREADY | j 

L X X J 



LINE PROCEDURE SPECIFICATION (LPS) 



The procedure to be followed by a message 
control program in operating upon messages 
being received from or sent to remote ter- 
minals is defined by one or more user- 
written sequences of QTAM macro instruc- 
tions. Each sequence is called a line pro- 
cedure specification (LPS) . The user must 
prepare an LPS for each communication line 
group in the system. However, more than 
one line group may use the same LPS if they 
all require identical message control 
procedures . 



The purpose of the LPS is to define 
macro-introduced routines that: 

1. Examine and process control informa- 
tion in message headers. 

2,. Perform functions necessary to prepare 
message segments for processing by 
message processing programs, or for 
forwarding to destination terminals. 

Preparing an LPS consists of selecting cer- 
tain of the QTAM macro instructions 
described in this chapter and writing them 
in a particular sequence, according to the 
requirements of the installation and of the 
line group. In preparing an LPS* the user 
must carefully analyze such considerations 
as the formats of message headers passing 
through the line group, the type of termi- 
nal and type of line (switched or non- 
switched) in the line group, and the pro- 
cessing requirements for various types of 
messages (if messages having different 
handling requirements are directed to the 
same LPS) . 

Two major types of macro instructions 
are used in the LPS: functional macro 
instructions and delimiter macro instruc- 
tions. In general,, the functional macro 
instructions perform the specific opera- 
tions required on messages directed to the 
LPS. Delimiter macro instructions classify 
and identify sequences of functional macro 
instructions and direct control to the 
appropriate sequence, according to whether 
the message segment is incoming or outgo- 
ing, and whether it is a header segment or 
a text segment,. 



COMPONENTS OF THE LPS 



The LPS is divided into two major groups of 
macro instructions: the Receive group, 
which handles incoiring messages ; and the 
Send group, which handles outgoing mes- 
sages. In the coding of the LPS,, the 
Receive group must precede the Send group. 
Each of the major groups is further divided 
into three coding subgroups. The Receive 
Segment and Send Segment subgroups contain 
macro instructions concerned with all por- 
tions (both header and text) of incoming 
and outgoing messages, respectively. The 
Receive Header and Send Header subgroups 
contain macro instructions concerned only 
with the headers of incoming and outgoing 
messages. Macro instructions in the End 
Receive and End Send subgroups perform 
error-handling procedures for incoming and 
outgoing messages. 



The Receive Header and Receive Segment 
subgroups may each be used more than once 
within the Receive group. Similarly, the 
Send Header and Send Segment subgroups may 
be used more than once within the Send 
group,. For example, an application might 
require that different operations be per- 
formed for several different types of roes- 
sages directed to the same LPS; each of the 
message types could require a different 
header format. In such a case,, there could 
be a separate Receive Header subgroup to 
process the header of each message type. 
The user can include in his header formats 
a special mess age- type character for each 
type of message. The MSGTYPE functional 
macro instruction can be used to examine 
the message-type character and direct con- 
trol to the appropriate Receive Header 
subgroup. 



The sequence of the Receive Header and 
Receive Segment subgroups within the 
Receive group,, and the sequence of the Send 
Header and Send Segment subgroups within 
the Send group, may depend on which func- 
tional macro instructions are specified 
within the subgroups. For example, assume 
that the TIMESTMP iracro is included in the 
Receive Header subgroup, and that the TRANS 
macro is included in the Receive Segment 
subgroup. The TIMESTMP macro enters the 
time of day into the message header in 
EBCDIC form, and the TRANS macro translates 
all message segments from transmission code 
into EBCDIC. It is evident that the EBCDIC 
time information must be inserted after the 
header has been translated to EBCDIC, not 
before. The translate routine must there- 
fore be executed before TIMESTMP; hence, 
the Receive Segment subgroup, which con- 
tains the TRANS macro, must be executed 
before the Receive Header subgroup. ^yj 
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The End Receive and End Send subgroups 
may each be used only once and, if used, 
must be the last sections within the 
Receive and Send groups,, respectively. 

If only the IBM-provided macro instruc- 
tions and associated macro-introduced rou- 
tines are used in coding an LPS, the 
Receive Header subgroup is mandatory. The 
user may omit any other subgroup if it is 
not required for a particular application. 
For example, the Receive Segment and Send 
Segment subgroups may be omitted in a mes- 
sage switching application if all terminals 
involved use the same transmission code 
(that is, translation of the message text 
is not required) and none of the other 
functions that require translation are 
desired. Any or all coding subgroups may 
be omitted if the user prefers to write his 
own routines for the functions he requires. 
An LPS must contain, as a minimum* the 
LPSTART, POSTRCV, and POSTSEND delimiter 
macro instructions to provide the linkage 
between the LPS and the IBM-provided logic 
that supports the message control program. 

Figure 12 shows the various coding sub- 
groups that can be included in an LPS,, the 
delimiter macro instructions associated 
with each subgroup, and the functional 
macro instructions (in alphabetical order) 
that can be used in each subgroup. 



DELIMITER MACRO INSTRUCTIONS 



Delimiter macro instructions group the 
functional macro instructions into the 
various subgroups. They also perform 
initialization and control functions within 
the LPS. 

The LPSTART macro instruction identifies 
the beginning of the LPS and must be the 
first instruction in every LPS. The code 
generated by the expansion of LPSTART 
determines whether the message segment en- 
tering the LPS is incoming or outgoing and 
directs the segment to the Receive group or 
the Send group accordingly. In an applica- 
tion that directs multisegment messages to 
the LPS, it is necessary that the function- 
al macro instructions in the header- 
processing subgroups be executed only where 
the message segment being handled contains 
the message header. The expansions of the 
RCVHDR and SENDHDR delimiter macro instruc- 
tions cause the header-processing subgroups 
to be bypassed when a message segment con- 
tains text only. 

POSTRCV and POSTSEND identify the ends 
of the Receive group and the Send group, 
respectively. These delimiters, along with 
LPSTART, must appear in every LPS. Each of 



the remaining delimiters is required only 
if the user chooses to include in the LPS 
the coding subgroup associated with that 
delimiter. 



FUNCTIONAL MACRO INSTRUCTIONS 



Functional macro instructions perform the 
specific operations required on message 
segments. These functions include: 

• Message editing (code translation and 
insertion of time of day, current date, 
and message sequence numbers in message 
headers) . 

• Checking validity of source and 
destination codes in message headers. 

• Routing messages to specified 
destinations. 

• Maintaining logs of messages on an 
auxiliary storage device,. 

• Checking for errors in message trans- 
mission and taking corrective action- 
Functional macro instructions that per- 
form operations related to an entire mes- 
sage segment may appear at any point within 
the coding subgroup in which they are used. 
All functional macro instructions in the 
Receive Segment, Send Segment, End Receive,, 
and End Send subgroups are included in this 
category. The majority of the functional 
macro instructions in the Receive Header 
and Send Header subgroups perform functions 
that concern a specific header field. 
Nacro instructions of this type involve 
either: 

1. Use of a QTAM scanning routine to 
determine the contents of a specific 
header field (e.g., SEQIN and SOURCE); 

2. Insertion of a new field in the mes- 
sage header (e.g.,, TIMESTMP and 
SEQOUT) ; or 

3. Making a decision at some point during 
header processing (e.g., MODE and 
MSGTYPE) 

These macro instructions must appear in a 
specific sequence dependent on the format 
of the message headers, 

In planning a format for message head- 
ers, the user may arrange the various head- 
er fields in any desired order. Macro 
instructions involving scanning,, insertion 
of a field, or making a decision must be in 
the same relative order as the correspond- 
ing message header fields on which they 
operate. Figure 12 indicates the function- 
al macro instructions that must be 
sequenced in this iranner. 
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Figure 12. Line Procedure Specification Macro Instructions 



Note : The entire header of each message 
must be contained within the buffer that 
receives the first segment of the message 
(see the BUFFER macro instruction descrip- 
tion). In addition, headers of messages 
that contain end-of-block characters must 
not extend past the first end-of-block 
character in the message. In no case may 
the header exceed 256 bytes in length. 

Some functional macro instructions that 
use the scanning routine provide the option 
of specifying the length of the header 
field to be scanned (e.g., ROUTE and 
SOURCE) . If the user does not specify the 
length, the field is assumed to be of vari- 
able length and must end with a blank char- 
acter. No blank character may appear 
within the field because it will be mis- 



taken for the end-of-field delimiter. If 
the field length is specified, the field to 
be scanned need not end with a blank char- 
acter,, and may contain embedded blanks, 
which will be skipped. 



THE SCAN POINTER 



In QTAM, general register 5 is used as the 
scan pointer register, maintaining a point- 
er to the current field in the message 
header. From the user's standpoint,, this 
pointer is his key to QTAM. Through the 
use of QTAM macro instructions, the user 
manipulates this pointer,, examines fields 
in the header, and makes decisions based on 
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the contents of these fields. In designing 
a QTAM message control program, the user 
must be constantly aware of the header 
field about to be processed. 



QTAM macro instructions perform many 
varying functions from verifying sequence 
information to placing messages on destina- 
tion queues. The user can design a simple 
message switching application using QTAM 
macro instructions only, and no user code 
(see Appendix L) . More sophisticated ap- 
plications may require that the user use 
the scan pointer in his routines. 

There are basically two types of LPS 
macro instructions that cause the scan 
pointer to be moved. Examples can be found 
in Figure 13. 

A. Certain macros move the scan pointer 
along until a user-specified character 
sequence is found (SKIP X'15' ). After 
these macro instructions have com- 
pleted, the scan pointer is positioned 
to the last character in the sequence. 

B. Other macro instructions move the scan 
pointer a certain number of charac- 
ters. There are three ways this num- 
ber is determined. 

1- Certain macro instructions have a 
fixed count of characters 
(DATESTMP) or an assumed count to 
be used if no other count is sup- 
plied (TIMESTMP) . When this type 
of macro instruction is completed, 
the scan pointer points to the 
last character to satisfy the 
count. Any blank characters 
encountered are skipped over,. 

2. With certain macro instructions, 
the user may specify a number of 
nonblank characters to be consid- 
ered as the next field (ROUTE 3) . 
When these macro instructions are 
completed,, the scan pointer is 
positioned to the last character 
that satisfies the count. The 
user may send in RA L, and the 
field is still considered RAL. 
The scan pointer points to the L. 

3. With some macro instructions, the 
field may be variable in length 
(SOURCE) . In this situation, the 
field length is not specified by 
the user. The scan pointer is 
moved forward past any blanks that 
might precede the field. The 
field is then scanned for a blank 
delimiter. When these macro 
instructions have executed, the 
scan pointer points to the blank 
delimiter which follows the field. 



When a message is first received for 
processing by the receive portion of the 
LPS,, the space reserved by the LPSTART 
macro instruction for expansion has been 
filled with idle characters (X'17*). The 
scan pointer is positioned to the last of 
these idle characters. If no idle charac- 
ters are specified in the LPSTART macro 
instruction* the scan pointer points to the 
last byte of the header prefix. 

After the receive section of the LPS is 
completed,, the position of the scan pointer 
is saved in the MSPTR field of the header 
prefix, and the message is placed on the 
queue for its destination. When the mes- 
sage comes off the destination queue to go 
through the send portion of the LPS,, the 
scan pointer is restored to its former 
position, pointing to the last character of 
the last field processed- Additional sta- 
tus information may be inserted into the 
header before the message is finally 
transmitted,. 

A message processing program may gener- 
ate a response message containing idle 
characters before the header fields. When 
this message is retrieved from the destina- 
tion queue for transmission to the termi- 
nal, the scan pointer points to the last of 
these idle characters. If no idle charac- 
ters are in the message,, the scan pointer 
points to the last character in the header 
prefix. Macro instructions in the SENDHDR 
section of the LPS will bypass these idle 
characters in scanning for the beginning of 
the header field. 

The user may use the scan pointer in his 
own routines to perform header analysis not 
provided by QTAM. However,, he must take 
the responsibility of positioning the scan 
pointer to its proper position before 
executing the next QTAM macro instruction. 



ERROR HANDLING FUNCTIONAL MACRO 
INSTRUCTIONS 



Four functional macro instructions 
(CANCELM, INTERCPT, REROUTE, and 
ERRMSG) „ called error macro instructions, 
permit the user to test for conditions for 
which he wishes appropriate action to be 
taken. These macro instructions are used 
in conjunction with the error halfword for 
the communication line involved. The error 
halfword consists of sixteen bits, and is 
located at LCB+40 (dec) or at reg4+40 
(dec). Each bit (except unused bits) indi- 
cates the presence (when 1) or absence 
(when 0) of a specific error or condition 
that has affected or may affect successful 
transmission of a message. The meaning of 
each of the bits is explained in Figure 14. 
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Position of Scan Pointer is at: 
© After LPSTART and RCVHDR have been issued. 
© After SKIP X'15" has been issued. 
© After SOURCE has been issued. 
© After ROUTE 3 has been issued. 



After DATESTMP is issued: 
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The DATESTMP macro instruction causes the 
header contents to be shifted 9 spaces left to 
make room for the date. The date is inserted 
and the scan pointer is positioned at (e) . 



•Figure 13. Scan Pointer Movement 



The user specifies a halfword bit con- 
figuration (called a mask) in each error- 
handling macro instruction used. Upon com- 
pletion of transmission of each message (or 
each block of a message) , the mask is com- 
pared to the error halfword. If a 1 is 
detected in any bit position of both the 
mask and the error halfword,, the function 
specified by the macro instruction is per- 
formed. A is specified in a mask bit 
position when the error or condition repre- 
sented by the corresponding position in the 
error halfword is to be ignored. 

The user may cause the function speci- 
fied by the macro instruction tc be per- 
formed unconditionally (that is ; , for all 
messages or message blocks) by specifying a 
mask consisting entirely of zeros. 

The user must analyze the requirements 
of his application to determine which 
errors or conditions must be detected and 
which can reasonably be ignored without 
degrading the performance of his system. 
The four error-handling macro instructions 
provide varying methods by which corrective 
or control functions can be initiated when 
an error has been detected. 

The ERRMSG macro instruction is used to 
send an appropriate message to a designated 
destination when any error specified by the 
mask has occurred,. For example, if an in- 



valid destination code is detected during 
receipt of a message, the ERRMSG macro 
instruction could be used to send a message 
to the originating terminal stating the 
nature of the error and requesting that the 
message be corrected and sent again. The 
INTERCPT macro instruction suppresses the 
sending of messages to a terminal when any 
error specified by the mask has been 
detected; it is normally used to withhold 
transmission to a terminal that has become 
inoperative.. The section on Functional 
Macro Instruction Descriptions contains 
detailed discussions cf these and the other 
error- handling macro instructions. 

The user must be very careful in testing 
the bits in the error halfword. Each cir- 
cumstance is special and there are no gen- 
eral rules on when to test a certain bit, 
Take the case where a user wishes to inter- 
cept all messages to a terminal when a con- 
trol mode time-out occurs at that terminal,. 
(A control mode time-out occurs when more 
than the maximum allowable time elapses 
between polling or addressing of a termi- 
nal, a,nd receipt of a response from that 
terminal.) A mask of X'4048* in the 
INTERCPT macro instruction will assure that 
the message in error and all following mes- 
sages to that terminal will be intercepted. 
Also, the user would like to be notified 
when this error occurs at the terminal. A 
mask of x'4048* in the ERRMSG macro 
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instruction will cause the specified error 
message to be sent whenever any message for 
that terminal is intercepted as a result of 
the time-out error- The generation of the 
error message will continue for each mes- 
sage intercepted until the problem at the 
terminal is corrected or until a RELEASEM 
is issued for that terminal. 

The user might not wish to be notified 
every time a message for that terminal is 
intercepted after the first one. A mask of 
X' 0048* in the ERRMSG macro instruction 
would cause the error message to be sent 
only after the first message for that ter- 
minal is intercepted after the time-out. 

In contrast to IBM terminal, the TWX 
33/35 terminal normally times out when 
there are no messages to send instead of 
sending a negative response. It is recom- 
mended that the user not send an error mes- 
sage to a TWX terminal for a time-out indi- 
cation, because this causes the repoll,, 
time-out, and * message sequence to be con- 
tinually repeated,. 

This is only an example of a particular 
case, but it shows the difference in per- 
formance with different bits tested. 

Note ; It is particularly important to 
specify some action to be taken in the 
event that a message sent to a terminal is 
not received by the terminal owing to line 
or terminal failure. If no action is 
taken, there is no record of which messages 
have been lost because of such failure. 



ARRANGEMENT OF LPS MACRO INSTRUCTION 
DESCRIPTIONS 



There are two major types of LPS macro 
instructions : 

1- Delimiter macro instructions. 

2- Functional macro instructions. 

Because the decision as to which macro 
instructions should be included in an LPS 
and how they should be sequenced depends 
greatly on the particular application, no 
attempt is made to discuss the macro 
instructions in any logical order. The 
macro instruction descriptions are arranged 
alphabetically by major type for easy 
reference. 

Note : The user is cautioned against 
transferring control between macro instruc- 
tions within the LPS. A user-written 
branch to a macro instruction may require 
that the user also perform functions (such 
as register saving and restoring) normally 



provided by the IBM-supplied coding. Since 
user-written branches are the exception 
rather than the rule, the name fields in 
the macro instruction formats for the LPS 
macro instructions (with the exception of 
LPSTART) have been omitted. 

It is recommended that the user not 
include comments on macro definition state- 
ments because they may be interpreted as 
operands. 



DELIMITER MACRO INSTRUCTION DESCRIPTIONS 



LPS delimiter macro instructions are used 
to group the functional macro instructions 
into the various coding subgroups. They 
also provide initialization and control 
functions within the LPS, 



End Receive (ENDRCV) Macro Instruction 



ENDRCV identifies the beginning of the End 
Receive coding subgroup of the LPS. The 
functions specified in this subgroup are 
performed after an entire message has been 
received by the coirputer. 

If EOB or EOBLC is specified, the func- 
tional macro instructions preceding the EOB 
or EOBLC in this subgroup will be performed 
for each message block; the functional 
macro instructions following the EOB or 
EOBLC will be performed only after the 
entire message has been received. (See the 
descriptions of the EOB and EOBLC macro 
instructions. ) 

If the End Receive subgroup is used, it 
must begin with the ENDRCV macro instruc- 
tion. It must be the last subgroup in the 
Receive group and can be used only once in 
the LPS. No operand is required. 



j Operation | Operand 
j. + 

j ENDRCV j 

l J. 



End Send (ENDSEND) Macro Instruction 



ENDSEND identifies the beginning of the End 
Send subgroup of the LPS. The functional 
macro instructions included in this sub- 
group are executed after an entire message 
has been sent by the computer, or after a 
message block has been sent if EOB or ECBLC 
is included as the last macro instruction 
in the subgroup. (See the descriptions of 
the EOB and EOBLC iracro instructions.) 
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Bit Function and Explanation 

Invalid destination code . The ROUTE macro instruction found a destination 
code in the message header for which there is no corresponding destination 
name in the terminal table. The message for the invalid destination is 
placed on the dead-letter queue. (For explanation of dead-letter queue, see 
Appendix K.) If a CANCELM macro instruction is given for this error condi- 
tion, the message is cancelled for any destinations whose codes follow the 
invalid one in the message header, as well as for the invalid destination. 

1 Terminal inoperative . The message was not sent to its destination because 
the "send" bit (bit 6 of the TSTATUS field) in the terminal table entry for 
that destination is off (i.e«, a zero bit). 

2 Sequence number high . The SEQIN routine found a message sequence number 
higher than the expected number for the next message originating from that 
terminal. If the iressage is not cancelled by the user, the same sequence 
number may appear in more than one message. When this error is detected, the 
expected sequence number is not changed. 

3 Sequence number low . The SEQIN routine found a message sequence number lower 
than the expected number for the next message originating from that terminal. 
If the message is not cancelled by the user, the same sequence number may 
appear in more than one message. When this error is detected,, the expected 
sequence number is not changed. 

4 Not used . This bit is not available to the user. 

5 Incomplete header . The incoming message header did not terminate within the 
first message segment (or prior to the first end-of-block character). 

6 Invalid source code . The Source routine found that the source field in the 
incoming message header contained a code that: (1) did not correspond to the 
name of the terminal that was connected to the computer over a nonswitched 
line, or (2) did not correspond to any terminal name in the terminal table 
(applicable only to switched terminals) . 

7 Should not occur . Error Recovery Procedures have detected an error that is 
not listed. 

8 Transmission error . Any error in transmission, such as a longitudinal or 
vertical redundancy check, time-out, intervention required, or unsuccessful 
identification exchange over WTTA lines, occurred during the receiving or 
sending of a message. If the error occurred during polling or addressing, 
bit 12 will also be on. If not, bit 12 will be off. 

9 Time-out exceeded . The maximum allowable time interval between reception of 
successive characters of a message, or between polling/addressing of a termi- 
nal or component and receipt of a response from the terminal has been 
exceeded, indicating possible terminal or line failure. If the error 
occurred during polling or addressing, bit 12 will also be on. If not* bit 
12 will be off. This bit will be on whenever a time-out or intervention 
required error has occurred. 

L 

Figure 14. Communication Line Error Halfword (Part 1 of 2) 
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Bit Function and Explanation 

10 Breakoff error . The BREAKOFF routine found an incoming message whose length 
exceeded the maximum allowable length, or one in which all of the characters 
in one of the buffers containing the message were identical (indicating line 
trouble) . 

11 Insufficient buffers . The QTAM buffer assignment routine was unable to pro- 
vide buffers for an incoming message. Infrequent occurrences of this condi- 
tion may be corrected by requesting the originating terminal to resend the 
message. Frequent occurrences of this condition require that QTAM be rede- 
fined with a larger number of buffers. 

12 Message not sent . This bit is set when a remote terminal is polled and does 
not receive a response, when a remote terminal is addressed and does not send 
a positive response, or when there has been an unsuccessful identification 
exchange at the beginning of an output message on WTTA lines- In these three 
instances a control mode error has occurred such as time-out or intervention 
required (bit 9 is also set) . If the bit is off,, the terminal is in text 
mode. Therefore, if an error bit other than bit 12 was set,, the error 
occurred during actual message transmission. If bit 8 is also set, an unsuc- 
cessful identification exchange has occurred on WTTA lines. The user may 
test this bit (LCBERRST + 1 = X*08') before his error handling macros to 
avoid handling control mode errors by the error macros,. 

13 Control Unit Failure . Error Recovery Procedures have detected an error that 
was caused by the control unit. 

14 and 15 For internal use by QTAM. 

L 

Figure 14. Communication Line Error Half word (Part 2 of 2) 



If the End Send subgroup is included, it 
must begin with the ENDSEND macro instruc- 
tion. It must be the last subgroup in the 
Send group and can be used only once in the 
LPS. No operand is required. 

If EOB or EOBLC is specified,, the func- 
tional macro instructions preceding the EOB 
or EOBLC in this subgroup will be performed 
for each message block; the functional 
macro instructions following the EOB or 
EOBLC will be performed only after the 
entire message has been sent. 

r t 1 

| Operation | Operand | 

j. + 1 

| ENDSEND | | 
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tering the LPS is incoming or outgoing,, and 
directs the segment tc the Receive group or 
the Send group, accordingly. 



r t t 

| Name | Operation | Operand 

| lpsname j LPSTART | [nn* ] 

| j | TERM= (termcode i# .. , 

| | | [,, INTRCPT=/YES\] 

II I \NO I 
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lpsname 

the total name of the macro instruc- 
tion; it is required. It must be the 
same as lpsnaire specified in the CLPS 
keyword operand cf the DCB macro 
instruction for the line group,. 



Line Procedure Specification Start 
(LPSTART) Macro Instruction 



The LPSTART macro instruction provides an 
initialization procedure for the LPS. 
LPSTART is required and must be the first 
macro instruction in every LPS. 

The code generated by the expansion of 
this macro instruction makes a test to 
determine whether the message segment en- 



the total number of bytes to be 
reserved in the message header in the 
first buffer of each input message for 
insertion of time-of-day, current- 
date,, and output- sequence-number 
information and insertion of the ECA 
for the 115A or 83B3 terminals if they 
are used for output. (see TIMESTMP, 
DATESTMP, and SEQOUT macro instruction 
descriptions and the section Exchang- 
ing Messages Between IBM and non-IBM 
Terminals) . If this operand is 
omitted, no space is reserved,. The 
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TERM 



number of bytes reserved must be 
included in the calculation of the 
buffer size (see BUFFER macro instruc- 
tion description) . 



this parameter must be included in 
each LPSTART macro instruction. 



Value description: 
(termcode lf . . . ) 

is the identifying code for the types 
of terminals for which terminal tests 
will be provided. The following 
values can be included in the sublist: 

1. 1030 specifies IBM 1030 
terminals. 

2. 1050 specifies IBM 1050 
terminals. 



Post Receive (POSTRCV) Macro Instruction 



POSTRCV identifies the end of the instruc- 
tion sequence that processes incoming mes- 
sages, that is„ instructions in the Receive 
Segment, Receive Header, and End Receive 
coding subgroups. 



One POSTRCV macro instruction is 
required in each LPS* and it must be the 
last instruction in the Receive group. No 
operand is required. 

r t 1 
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3. 1060 specifies IBM 1060 
terminals. 

4. 2848 specifies IBM 2848 control 
units (associated with remote IBM 
2260 terminals) . 

5. 2740 specifies IBM 2740 

6. 83B3 specifies ATST 83B3 selec- 
tive calling stations. 

7. 115A specifies Western Union Plan 
115A out stat ions. 

8. TWX specifies common carrier TWX 
stations. 

9. WTTA specifies World Trade tele- 
graph terminals 



Post Send (POSTSEND) Macro Instruction 



POSTSEND identifies the end of the instruc- 
tion sequence that processes outgoing mes- 
sages, that is, instructions in the Send 
Header, Send Segment, and End Send coding 
subgroups. 

One POSTSEND is required in each LPS, 
and it must be the last instruction in the 
Send group. No operand is required. 

r t 1 
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Note : On-line terminal tests will not be 
made on Teletype terminals (numbers 6,, 7, 

18, and 9 above), but they must be specified 
if that terminal type is included in this 
LPS. 

INTRCPT=YES 

this operand must be specified if the 
INTERCPT or RELEASEM macros are used 
in the LPS, or if the operator control 
function is to intercept or release a 
terminal that uses this LPS. 

INTRCPT=NO 

if INTRCPT=NO is specified, or if this 
operand is omitted, the Release and 
Intercept facilities must not be used. 



Note: 



If the user wishes to use the 



intercept-release function in conjunction 
with checkpoint-restart, then an additional 
parameter must be included in the user* s 
LPSTART macro defining the name of the 
intercept OPTION field in the TERM entries . 



Receive Header (RCVHDR) Macro Instruction 



RCVHDR identifies the beginning of the 
Receive Header subgroup, which contains 
instructions concerned only with the header 
portions of incoming messages,. The 
instructions generated by the expansion of 
this macro instruction test whether the 
message segment being operated on contains 
the message header or text only. If the 
segment contains text only, the functional 
macro instructions in the Receive Header 
subgroup are bypassed; if the segment con- 
tains the message header, the instructions 
in the Receive Header subgroup are 
executed. 

If the Receive Header subgroup is 
included in the LPS, it must begin with the 
RCVHDR macro instruction- No operand is 
required. 
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Receive Segment (RCVSEG) Macro Instruction 



Send Segment (SENDSEG) Macro Instruction 



SENDSEG identifies the beginning of the 
Send Segment subgroup,, which contains 
instructions concerned with both header and 
text portions of outgoing messages. 

If the Send Segment subgroup is included 
in the LPS, it must begin with the SENDSEG 
macro instruction. Nc operand is required. 



RCVSEG identifies the beginning of the 
Receive Segment subgroup, which contains 
instructions concerned with both header and 
text portions of incoming messages. 



r t 1 

| Operation ] Operand | 
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If the Receive Segment subgroup is 
included in the LPS, it must begin with the 
RCVSEG macro instruction. No operand is 
required. 



FUNCTIONAL MACRO INSTRUCTION DESCRIPTIONS 



r t 1 

| Operation | Operand | 
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| RCVSEG | | 
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LPS functional macro instructions perform 
specific operations concerned with message 
segments. The appropriate functional macro 
instructions must be selected and properly 
sequenced to satisfy the specific handling 
requirements of messages directed to the 
LPS. 



Send Header (SENDHDR) Macro Instruction 



Halt Receive (BREAKOFF) Macro Instruction 



SENDHDR identifies the beginning of the 
Send Header subgroup, which contains 
instructions that process only header por- 
tions of outgoing messages. The code 
generated by the expansion of this macro 
instruction includes instructions that test 
whether the message segment being operated 
on contains the message header or text 
only. The functional macro instructions in 
the Send Header subgroup are executed if 
the segment contains the message header; 
they are bypassed if the segment contains 
text only. 

The user must be sure that the proper 
EOA sequence is to be transmitted with the 
message. A discussion of the EOA sequences 
for different terminals can be found in 
Appendix H- 

If the Send Header subgroup is included 
in the LPS, it must begin with the SENDHDR 
macro instruction. No operand is required. 
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BREAKOFF is used to specify a maximum 
length for each incoming message. If the 
message exceeds the maximum length, recep- 
tion of the message is terminated and an 
error flag is set in bit ten of the error 
half word for the line. This macro instruc- 
tion also checks if the input buffer is 
filled with identical characters. If it 
is, the same action is taken as described 
above. (A long sequence of identical char- 
acters is usually an indication of terminal 
malfunction. ) 

Use of BREAKOFF is optional. If used* 
it must appear within the Receive Segment 
coding subgroup. 

BREAKOFF can be used only for messages 
from 115A and 83B3 Teletype terminals. 

r t 1 
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nnnnn 



the maximum number of characters for 
each message. The maximum value of 
"nnnnn" is 32767. 
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Cancel Message (CANCELM) Macro Instruction COUNTER Macro Instruction 



CANCELM is an error-handling macro instruc- 
tion that causes immediate cancellation of 
a message if any of the errors specified by 
the mask has been detected™ Cancellation 
means that the message is not sent to the 
destination (s) specified in the message 
header ( handled by the ROUTE macro ) , or by 
the DIRECT macro. If CANCELM is used to 
test for an invalid destination code and 
the error has occurred,, the message is can- 
celled for the invalid destination and for 
any destinations whose codes follow the in- 
valid one in the message header. If a mes- 
sage is cancelled, any subsequent EOB or 
EOBLC in the subgroup that handled the mes- 
sage will have no effect. 



If a message is not sent to its intended 
destination due to cancellation, it is 
important that some action be taken to 
notify a terminal operator or to perform 
some other corrective action. If no action 
is taken, there is no record of which mes- 
sages have been lost because of cancella- 
tion. The ERRMSG macro instruction can be 
used to send a message to a terminal noti- 
fying its operator of the error; or the 
REROUTE macro instruction can be used to 
send the message in error to a selected 
terminal (see the descriptions of these 
macros) . CANCELM must precede an ERRMSG or 
REROUTE macro instruction used to test for 
the same error condition in the End Receive 
' subgroup. CANCELM cannot be used to cancel 
messages for a PROCESS EXPEDITE queue or 
multisegment messages in initiate mode 
(since cancelled messages must be recalled 
from the DASD destination queue) . 



The meaning of the bits in the error 
halfword tested is shown in Figure 14.. 

Use of CANCELM is optional. If used,, it 
must appear within the End Receive subgroup 
of the LPS, It should not be placed after 
an ERRMSG or REROUTE macro instruction. 
Since all errors requiring message cancel- 
lation can be specified in the same error 
mask, only one CANCELM macro instruction is 
needed in the End Receive subgroup. 

r * t 1 

| Operation | Operand | 
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mask 



the hexadecimal representation of the 
bit configuration used to test the 
error halfword for the communication 
line involved. The fr airing X and 
quotes must be coded. 



COUNTER enables the user to maintain four 
types of count: 



Incoming message segments from each 
originating terminal if EOBs are not 
used in the message; incoming message 
segments plus message blocks if EOBs 
are used in the message. 



2. Incoming messages from each origina- 
ting terminal. 

3. Outgoing message segments for each 
destination terminal. 

4- Outgoing messages for each destination 
terminal or terminal component that 
has a single terminal entry in the 
terminal table. 

The position of the COUNTER macro 
instruction within the LPS determines which 
of the four types of count will be main- 
tained. COUNTER must appear in the Receive 
Segment subgroup to count incoming message 
segments, in the Receive Header subgroup to 
count incoming messages,, in the Send Seg- 
ment subgroup to count outgoing message 
segments,, and in the Send Header subgroup 
to count outgoing messages. Any one or all 
four counts can be maintained by including 
the COUNTER macro instruction in the appro- 
priate subgroups ; within each subgroup, it 
may appear at any point,. 

For each COUNTER macro instruction 
issued, the user must define, by means of 
one OPTION macro .instruction,, a halfword 
field for each entry in the terminal table 
defined by a TERM macro instruction. This 
provides space for maintaining the 
messages-per-terminal or message segments- 
per- terminal count. The number of COUNTER 
macro instructions used in the LPS, and the 
number of OPTION macro instructions for the 
count fields must each correspond to the 
number of counts being maintained. See the 
OPTION macro instruction description. 

Use of COUNTER is optional. If it is 
used in the Receive Header or Receive Seg- 
ment subgroup and the terminals for which 
it maintains counts are on a switched line, 
COUNTER must be preceded by a SOURCE macro 
instruction. If COUNTER is to be used to 
count segments over a switched line, there 
must be two Receive Segment subgroups in 
that LPS„ one before the Receive Header 
subgroup containing the required SOURCE 
macro, and one following it. The first 
Receive Segment subgroup will translate the 
message segment and the second will count 
the segments. 
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Note: 



If COUNTER is used to record incom- 



ing messages from a line group to which IBM 
22 60s are attached, all segments received 
from the various 2260s during a general 
poll are counted as one message. 

r t 1 

| Operation | Operand | 
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field 



the name of a halfword field in the 
user's area of each single terminal 
entry in the terminal table, as 
defined by an OPTION macro instruc- 
tion. The field contains a binary 
count up to a maximum of 32,7 67. When 
the maximum count has been reached, 
the count is reset to 1 for the next 
message or segment counted. The user 
may access the field at any time to 
determine and/or reset the count. 



Date Stamp (DATESTMP) Macro Instruction 



DATESTMP causes insertion of the date in 
the message header. DATESTMP can be 
included for incoming messages, outgoing 
messages, or both. The date is expressed 
as byy.ddd, where b is a blank, yy is the 
year, and ddd is the day of the year (for 
example, b67.2 89). 

No operand is necessary in this macro 
instruction because the date field has a 
fixed length of seven. When DATESTMP is 
specified, the user must include the length 
of the inserted fieltf (seven bytes) in his 
calculation of the value of the operand in 
the LPSTART macro instruction (see the 
LPSTART macro instruction description) . 

Use of DATESTMP is optional. Tf used, 
it must appear in the Receive Header or 
Send Header subgroup. Its position within 
the subgroup must correspond to the rela- 
tive position within the header of the 
field in which the current date is to be 
inserted. 
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DIRECT Macro Instruction 



DIRECT causes a message to be queued for 
the destination specified by the operand. 
Any destination for which there is an entry 



in the terminal table may be specified. 
DIRECT may be used in place of ROUTE when 
message headers do not contain destination 
codes. Either DIRECT or ROUTE must be 
specified to handle message routing; both 
cannot be used, Only one DIRECT macro may 
be used for each Receive Header subgroup or 
for each message type used within one 
Receive Header subgroup. 



DIRECT may be used only within the 
Receive Header subgroup. If DIRECT is 
used, EOA must not be specified. 



Note : If the TERM macro instruction speci- 
fies that the IBM 2260-2848 complex is to 
be polled using the general poll feature, 
the DIRECT macro instruction must be used 
to send incoming messages to a message pro- 
cessing program- The processing program 
must then analyze the message., which con- 
sists of segments from different 2260s # and 
place each segment on the proper DASD 
destination or process queue. 
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dest 



the destination code, which may be the 
name of any entry in the terminal 
table. "n" must be equal to or great- 
er than the longest such name appear- 
ing in the terminal table; or "n" may 
be 8 (the maximum allowable length) . 
"n" may be omitted if this destination 
name is the same length as the longest 
destination name. 



subf ield 

the name of an optional subfield in 
the terminal table entry for the orig- 
inating terminal. This subfield con- 
tains the name of the terminal to 
which the message is to be sent. The 
name of the subfield specified by this 
operand must be the same as the name 
assigned to the subfield by an OPTION 
macro instruction. The contents of 
the subfield are specified by the TERM 
macro instruction that defines the 
terminal table entry for the origina- 
ting terminal (see the OPTION and TERM 
macro instruction descriptions). If 
the originating terminal is on a 
switched line, and the user wishes to 
use this operand, DIRECT must be pre- 
ceded by the SOURCE macro instruction. 
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End-of -Address (EOA) Macro Instruction 



Hardware Error Checking 



EOA is required if the user wishes to pro- 
vide multiple routing of incoming messages. 
The instructions generated by this macro 
instruction determine the end of the list 
of destination codes in the message header. 
The character specified by the EOA macro 
instruction must appear in the header of 
each message after the last destination 
code, regardless of the number of destina- 
tion codes in the header. 

When used, this macro instruction must 
immediately follow the ROUTE macro instruc- 
tion. EOA is not used if DIRECT is 
specified. 



Restriction : EOA must not be used for any 
message whose destination is a processing 
program queue identified by a PROCESS 
EXPEDIT^-defined EXPEDITE terminal table 
entry. Messages to a PROCESS EXPEDITE 
queue may not be routed to more than one 
processing program station. 
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eoa 



the EOA character that irust appear in 
the message header after the last 
destination code. If the destination 
codes all have the same length, and 
the optional operand in the ROUTE 
macro instruction is specified, no 
blank is required between the last 
code and the EOA character. Other- 
wise, a blank must separate the two. 
Any nonblank character iray be speci- 
fied as the EOA character. The EOA 
character may be specified either as 
the character itself, or as the hexa- 
decimal equivalent of the character. 
The framing C or X and quotes must be 
coded. 



Examples : In an EOA macro instruction that 
specifies a # to be used as an EOA charac- 
ter, the # may be written either as the 
character itself, or in hexadecimal repre- 
sentation of the EBCDIC equivalent of that 
character: 

r t 1 

| Operation (Operand | 
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|EOA |C'#' | (1) 
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Two QTAM macro instructions are provided to 
support the hardware error-checking and 
retry capabilities available with IBM ter- 
minals. The design of these macros, EOB 
and EOBLC, permits the use of any of the 
following hardware functions. 

1. LRC/VRC checking only (e.g., 1060 ter- 
minals) - Checking is provided,, but no 
automatic (hardware) retry of errors. 

2. LRC/VRC checking with automatic line 
correction (e, g.„ 1050) - Checking and 
retry of error is provided,, but manual 
intervention is required after a per- 
manent error is established. 

3. LRC/VRC checking with automatic line 
correction and release (e.g., 1050) - 
Checking and retry of errors is pro- 
vided without manual intervention 
after a permanent error. 

In the case of basic terminals (e.g., 
2740 Type I or Type III), neither the ECB 
or EOBLC capability is to be used. EOBLC 
capability is to be used. 

In case 1 above, the EOB macro is 
required following the ENDRCV and ENDSEND 
macros of the corresponding LPS. For read 
operations, a positive response will be 
returned to the terminal after a block has 
been successfully read; no response will be 
returned after the read was unsuccessful. 
QTAM will assume that the message is com- 
pleted and re- poll for the next message. 
For write operations^ QTAM will transmit 
the next block of a message following a 
successful one. It will consider an unsuc- 
cessful block as the termination of the 
message. 

Manual intervention is required to reset 
the terminal upon occurrence of errors. 

In case 2 above, the EOBLC macro is 
required in place of the EOB. Its only 
functional difference from the EOB support 
is in handling of unsuccessful message 
blocks. Message blocks causing an error 
are retried twice before they are consid- 
ered unsuccessful and the message is ter- 
minated. Retries are for both read and 
write operations. Manual intervention is 
required to reset the terminal upon occur- 
rence of errors. In read operations, the 
operator must set his terminal to transmit 
the next segment of the message, or EOT, 
before starting his next message. 

Case 3 above differs from case 2 in one 
instance only. The remote terminal will* 
without any manual intervention, continue 
to transmit the remainder of the message- 



Message Control Program 73 



QTAM will continue to receive and process 
the remainder of the message. 

In both cases 2 and 3, transmission of a 
message from the CPU will terminate after 
the second retry of an unsuccessful block. 
Also, error indications for unsuccessful 
blocks in input transmissions will be saved 
in the error halfword. Error indications 
for a specific block are available in the 
error halfword during the LPS processing of 
that block (prior to the EOBLC macro state- 
ment) ; error indications for all blocks in 
the transmission are available in the error 
halfword during LPS processing following 
receipt of EOT (following the EOBLC macro 
statement) . 



End-of-Block (EOB) Macro Instruction 



An LRC check is performed each time an end- 
of-block (EOB) or end-of-text (ETX) charac- 
ter is encountered in message text. The 
check is made by the data adapter at the 
central processing location for incoming 
messages, and by the terminal control unit 
for outgoing messages. The EOE causes a 
positive response to be sent to the source 
of the message, if the data was received 
correctly. If the 2740 Model 2 is equipped 
with the checking feature, the transmission 
of EOB is a hardware function. According- 
ly, the EOB or EOBLC macro instruction must 
be issued in the End Receive and End Send 
sections of the LPS. 

The EOB macro must normally be speci- 
fied, in both the End Receive and End Send 
subgroups of each LPS that handles messages 
to and from an IBM 1030, 1050, 1060, 2260, 
or 2740 types IV through VII. The EOB 
macro (or EOBLC macro, as subsequently 
explained) must be specified for a 2260- 
28 48 for which general polls are to be per- 
formed. It may be omitted only if all mes- 
sages are one block long and if possible 
errors are to be ignored (both conditions 
are required) . Either the EOBLC or the EOB 
macro instruction must be specified in both 
the End Receive and the End Send subgroups 
of each LPS that handles messages for an 
IBM 2740 Model 2 terminal. 

This macro instruction is used only for 
the terminal types just cited. In the case 
of the IBM 1050, 2260, and 2740 (types IV 
through VII) , the EOBLC macro instruction 
(subsequently discussed) may be specified 
instead of the EOB macro. 



minal to send another message block. If 
the data was incorrectly received, no 
response is sent; reception of the message 
is terminated. The terminal must resend 
the message block when contact with the 
computer is reestablished (by polling or 
dialing). Either the EOBLC or the EOB 
macro instruction must be specified in both 
the End Receive and the End Send subgroups 
of each LPS that handles messages for an 
IBM 2740 Model 2 terminal. 



For Outgoing Messages ; The EOB macro 
causes an EOB (or ETX), followed by an LRC 
character, to be sent to the terminal when 
an EOB (or ETX) character is encountered in 
message text. If the terminal receives the 
message data correctly, it returns a posi- 
tive response. Upon recognizing this 
response, the computer sends the next mes- 
sage block. If the terminal receives the 
data in error, it returns a negative 
response. Upon receiving this response the 
computer terminates transmission of the 
message. 



If the EOB macro is not specified, the 
first EOB (or ETX) character encountered in 
incoming or Outgoing message text is 
treated as an en d-of- transmission (EOT) 
character, precluding transmission of any 
subsequent blocks of that message. 



Restriction : EOA irust not be used for any 



message whose destination is a processing 
program queue identified by a terminal 
table entry defined by PROCESS EXPEDITE. 
Messages to a PROCESS EXPEDITE queue may 
not be routed to another terminal or pro- 
cessing program. 



Note ; Error-handling macros should not 
precede the EOB macro because if the speci- 
fied error condition occurs, the EOB macro 
will not be executed. The EOB character 
will be treated as an EOT, and the source 
terminal will not receive a response to the 
EOB- LRC sequence. 

Within the coding subgroup in which the 
EOB macro appears, all functional macro 
instructions that precede the EOB macro are 
executed for all message blocks. All func- 
tional macros that follow the EOB macro are 
executed only at the end of the message (an 
EOB is treated as an end of message if a 
transmission error occurred during trans- 
mission of the block) . 



For Incoming Messages : The EOB macro 
causes a positive response to be sent to 
the terminal if the message data was 
correctly received. This permits the ter- 
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End-of-Block and Line Correction (EOBLC) 
Macro Instruction 



EOBLC is an optional macro instruction used 
only for: 

1. An IBM 1050 with automatic line 
correction feature. 

2. An IBM 2260-2848. 

3. An IBM 2740 equipped with the checking 
feature (types IV through VII). 

4. An IBM 1030 - on read operations, the 
EOBLC macro must be followed by a 
CANCELM macro specifying data check. 

5. An IBM 1060 - on read operations only, 
the EOBLC macro must be followed by a 
CANCELM macro specifying data check, 

EOBLC performs the same function and is 
used in the same manner as the EOB macro. 
In addition, it returns a negative response 
to the message source if the data was in- 
correctly received, permitting the source 
to resend the erroneous message block. If 
the 2740 Model 2 is equipped with the 
checking feature, the transmission of EOB 
is a hardware function. Accordingly, the 
EOB or EOBLC macro instruction must be 
issued in the End Receive and End Send sec- 
tions of the LPS. 



For Incoming Messages ; 

1. For an IBM 1050 not equipped with the 
line correction feature, resending is 
accomplished by rekeying the message 
block in error, or by repositioning 
the paper tape or card containing the 
erroneous block. 

2. For an IBM 2740, resending is accom- 
plished by rekeying the message block 
in error. 



If EOBLC is specified, any message block 
whose transmission resulted in an error is 
retransmitted a maximum of two times. If 
the error persists after the second retry, 
an error flag is set in the error harlfword 
for the line (see Figure 14). 

Restriction : EOBLC must not be used for 
any message to a PROCESS EXPEDITE queue or 
multisegment messages in initiate mode. 
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Error Message (ERRMSG) Macro Instruction 



ERRMSG causes a user-written error message 
to be sent to a designated terminal when 
one of the errors specified by the error 
mask has occurred. 

By means of the ERRMSG macro, the user 
specifies: 

1. The bit configuration of the mask used 
to test the error half word. 

2. The destination to which the error 
message is to be sent. 

3. The text that is to comprise the error 
message,. 

The meaning of the bits in the error 
halfword tested is shewn in Figure 14. The 
error message includes the text written by 
the user and, optionally, the header of the 
message in error. The user specifies that 
the header is to precede the text by writ- 
ing a period as the first character of the 
text. The length of the complete error 
message cannot exceed one segment (that is, 
one buffer). 



3. For an IBM 2260, the terminal automat- 
ically resends the message block. 

4. For an IBM 1050 equipped with the line 
correction feature: 

a. If the erroneous message block 
originated from the paper tape 
reader or card reader, the device 
automatically repositions the tape 
or card and resends the block. 

b. If the erroneous message block 
originated from the keyboard, the 
operator rekeys the message block. 

For Outgoing Messages : For any of the 
above terminal types, the coirputer automat- 
ically resends the erroneous message block. 



Unless the MSGTYPE macro instruction is 
used to distinguish between different mes- 
sage types, the format of the header for an 
error message must be identical with the 
header format used for other outgoing mes- 
sages. If the MSGTYPE macro instruction is 
used for this purpose, the formats of the 
respective message headers for the two 
types may differ after the message-type 
character. In either case, the correct EOA 
character for the destination terminal must 
be included. 

If the ERRMSG macro does not specify 
that the message header is to be included 
with the error text, no LPS macros that 
refer to fields in the header may be used 
in the Send Header subgroup that is to pro- 
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cess the error message,, without some modi- 
fication by the user. 



For an ERRMSG macro that does not speci- 
fy inclusion of the header of the message 
in error, it is assumed that the user will 
place the machine EOA character or sequence 
in the first character position of the 
| error text (for the 22 60 STX is used).. 
This is required by the terminal to receive 
the error message regardless of which LPS 
macros are to process the error message. 
The scan pointer register, register 5, will 
thus be pointing to the first character of 
the message in error; this character will 
be the EOA character (or the first charac- 
ter of the EOA sequence) . If the user 
chooses to have a DATESTMP, TIMESTMP, or 
SEQOUT macro operate on a message in error 
that does not contain the header of the 
erroneous message, he must first set the 
scan pointer register to point to the first 
character following the machine EOA. This 
may be done by incrementing the register by 
the number of characters comprising the EOA 
sequence . 



If the incominq sequence number is in- 
valid, and an error message is to be sent, 
ERRMSG will scan the error message. If the 
special character $ is encountered, the 
correct input sequence number is moved into 
the four bytes following the $, and the $ 
is overlayed with a blank. If a second $ 
is found before the end of the error mes- 
sage, the invalid sequence number is moved 
into the four bytes following the $, and 
this second $ is also overlayed with a 
blank. If this function is not desired,, do 
not use the character $ in the error mes- 
sage for invalid input sequence number. An 
unconditional mask (X'OOOO') may not be 
used in this instance. If the message with 
invalid sequence number was sent from a 
terminal on a switched line, and this func- 
tion is desired, the SOURCE iracro instruc- 
tion must be used in the Receive Header 
subgroup of this LPS. This function does 
not pertain to PROCESS EXPEDITE queues. 



The CANCELM macro instruction should be 
used prior to the ERRMSG macro instruction 
if the message is to be cancelled. 



This macro instruction, if used, must 
appear within the End Receive and/or End 
Send subgroup of the LPS; it can appear 
more than once in either subgroup. 



Restriction : ERRMSG must not be used for 
any message whose destination is a process- 
ing program queue identified by a PROCESS 
EXPEDITE terminal table entry. 
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mask 



dest 



the hexadecimal representation of the 
bit configuration used to test the 
error half word. 



the destination code for the terminal 
to which the error message is sent; it 
may be the name cf any entry in the 
terminal table except a distribution 
list entry. "n" must be equal to or 
greater than the longest such name 
appearing in the terminal table. The 
maximum value for "n" is 8. "n" may 
be omitted if this destination name is 
the same length as the longest 
destination name. 

subf ield 

the name of a terminal table optional 
subfield that is associated with the 
name of the terminal from which the 
message in error originated. The 
error message is sent to the destina- 
tion whose name appears in the option- 
al field. 

SOURCE 

specifies that the error message is to 
be sent to the terminal from which the 

I message in error originated. For 
switched or Auto Poll lines,, SOURCE 
may not be used if this ERRMSG macro 
is used for an illegal source code 
error (that is, if the mask contains a 
j 1 in bit position 6) . 

message 

the actual text of the error message. 

msgchar 

the address of the first character of 
the error message text; it must be in 
the same CSECT as the macro 
instruction. 

Example : Shown in the following chart is 
an ERRMSG macro instruction used in the End 
Receive subgroup of an LPS to test for in- 
valid destination codes or erroneous 
sequence numbers. The first operand is the 
hexadecimal representation of the configu- 
ration (1011000000 000000) of the mask that 
tests bits 0,, 2, and 3 of the error half- 
word. The second operand indicates that 
the error message is to be sent to the ter- 
minal from which the message in error orig- 
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inated. The third operand is the address 
of the first character of the error message 
text. 

r t 1 

| Operation | Operand | 
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JERRMSG |X'B000 , ,SOURCE,ERMSG02 3 j 
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Example : Shown in the following chart is 
an ERRMSG macro instruction used in the End 
Send subgroup of an LPS to test for trans- 
mission errors in outgoing messages. The 
first operand is the hexadecimal represen- 
tation of the bit configuration 
(0000000100000000) of the mask that tests 
bit 8 of the error half word. The second 
operand is the name of the terminal to 
which the message in error is to be sent 
(all error messages are sent to the same 
terminal regardless of which destination 
terminal was to have received the erroneous 
message) . The third operand is the text of 
the error message. The period as the first 
character causes the header of the message 
in error, if there is a header for that 
message, to precede the text. (A polling 
error is an example of a message in error 
that has no header. In this case the head- 
er cannot be included in the error 
message. ) 

In general, if the error message is to 
be sent to an IBM terminal, it may end with 
an end-of -block character. 
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Intercept (INTERCPT) Macro Instruction 



INTERCPT causes the suppression of all mes- 
sage transmission to a terminal when any of 
the errors specified by the mask has been 
detected. The untransmitted messages 
remain on the DASD destination queue for 
that terminal. If the INTERCPT macro 
instruction is to be used, the user must 
specify a 3-byte subfield named INTERCPT in 
the optional user area of the terminal 
table. (See the OPTION macro instruction 
description. ) For each terminal for which 
message transmission is suppressed: 

1. The disk address of the first inter- 
cepted message header is placed in the 
INTERCPT subfield reserved in the 
entry representing that terminal. 

2. The intercept bit in the TSTATUS byte 
of that entry is set to 1. 



3. The send bit in the TSTATUS byte for 
that entry is set to 0. 

No further messages are sent to the 
affected terminal until the user resets the 
intercept and send bits. This may be done 
by a message processing program using the 
RELEASEM or CHNGT macro instruction or by 
issuing a RELEASEM or CHNGT operator con- 
trol message. If RELEASEM is used, all 
suppressed messages (those on the destina- 
tion queue) are sent, as are any new mes- 
sages. If CHNGT is used, only the new mes- 
sages (those placed on the destination 
queue after CHNGT has been issued) are 
sent. In the latter case, the suppressed 
messages remain on the destination queue, 
and cannot be sent unless the user obtains 
them by a RETRIEVE macro instruction and 
reissues a PUT for each of them. The mean- 
ings of the bits in the error halfword 
tested are shown in Figure 14. 

The INTERCPT macro instruction is used 
to permit messages on a line that were not 
transmitted to be sent at a later time. 
Note that after the first message has been 
intercepted for any condition specified, 
the send bit in the terminal table for the 
terminal will be turned off. Therefore,, 
all subsequent messages for that destina- 
tion will not be sent, but will be flagged 
as "terminal inoperative" in the error 
halfword. These subsequent messages will 
not be intercepted unless the error mask 
for the error halfword has terminal 
inoperative specified. If the terminal is 
equipped with the Buffer Receive option, 
the user must specify the INTERCPT macro 
instruction in the End Send section of the 
LPS with a mask including the 'message not 
sent' bit. This is necessary because the 
terminal may be addressed while a message 
is being entered at the terminal,, resulting 
in a negative response to addressing. If 
this happens, the terminal bell rings and 
the attention light is turned on. The 
intercepted message may be released by 
sending a message to a message processing 
program to issue a RELEASEM macro instruc- 
tion or by use of the Operator Control 
RELEASEM function. Refer to the RELEASEM 
macro description, noting particularly the 
necessity for a priming message. 

If the user ever wishes to issue an 
INTERCPT operator control message, he must 
specify the INTERCPT macro instruction in 
the ENDSEND portion of the LPS. The mask 
in this macro must specify "terminal 
inoperative" (i.e., the mask must be at 
least a hexadecimal 4000). 

The use of INTERCPT is optional. If the 
macro instruction is not used, messages 
that were unable to be transmitted are con- 
sidered as transmitted, even though they 
did not reach their destination. If used. 
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it must appear in the End Send subgroup of 
the LPS. 
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mask 



time-of-day information. (The logging 
effected by LOGSEG is in addition to the 
queuing procedure of QTAM. ) Use of LOGSEG 
is optional. 

r t * 1 
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the hexadecimal representation of the 
bit configuration used to test the 
error halfword for the communication 
line involved. 



Logging (LOGSEG) Macro Instruction 



LOGSEG enables the user to log message seg- 
ments (place them on an output device as a 
record of message traffic carried by the 
line group) . The user may maintain any or 
all of four types of logs by appropriate 
placement of LOGSEG within the LPS. The 
four types of logs, and the corresponding 
coding subgroup in which LOGSEG must 
appear, are: 

1. Incoming headers only (Receive 
Header) . 

2. All incoming segments if EOBs are not 
used in the message; incoming segments 
plus message blocks if EOBs are used 
in the message (Receive Segment), 

3. Outgoing headers only (Send Header). 

4. All outgoing segments (Send Segment). 

If all segments of messages are logged, 
they are logged in the sequence in which 
they are received or sent. Therefore,, seg- 
ments of different messages are intermixed 
on the log, not grouped together as indi- 
vidual messages. The last 24 bytes of a 
QTAM header prefix, preceded by 4 bytes of 
information used by the access method doing 
the logging, are recorded on the logging 
device. These bytes precede the header 
portion (and text portion, if any) of the 
first segment of a message. The last 14 
bytes of a QTAM text prefix, preceded by 4 
bytes of information used by the access 
method doing the logging, are recorded on 
the logging device. These bytes precede 
the text portion of a text message segment. 

LOGSEG may appear at any point in the 
subgroup in which it is used. However., the 
results of any alteration of segments by 
functional macro instructions preceding 
LOGSEG will appear in the logged segment. 
For example, if LOGSEG is preceded by 
TIMESTMP, all logged headers will contain 
time-of-day information. If TIMESTMP fol- 
lows LOGSEG, headers will be logged without 
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the name of the data control block for 
the message log data set. If register 
notation is used, (1) specifies that 
the address of the data control block 
is in parameter register 1. The 
address must be loaded into register 1 
prior to execution of this macro 
instruction . 



Message Mode (MODE) Macro Instruction 



MODE causes execution of a designated func- 
tion, either unconditionally (the desig- 
nated function is performed for all mes- 
sages handled by this portion of the LPS) 
or conditionally (if the next nonblank 
character of the message header is the same 
as a character designated by the MODE macro 
instruction) . 



In the second case, if the characters 
are not the same,, control returns to the 
next instruction in the LPS,, and the scan 
pointer is reset to its position prior to 
the comparison. 



MODE can cause the execution of any of 
four IBM-provided functions, or a user- 
written routine. The functions provided by 
IBM are discussed in the following operand 
descriptions. 



The message priority scheme implemented 
by the MODE macro instruction with the 
PRIORITY operand is designed to permit a 
message from one of a group of lines send- 
ing to a common destination to be sent 
ahead of the other messages in the queue 
for that destination. The priority routine 
compares the relative priority indicators 
of the last message sent from each line 
originating messages for the common 
destination. The highest- priority message 
is sent first, followed by the other mes- 
sages, in order according to their priori- 
ties, and then non-priority messages for 
the line. The priority conferred on a mes- 
sage is valid only if that message is the 
last message to be sent from that source 
line. If more than one message from the 
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line is currently being handled by QTAM, 
only the message that arrived last can have 
valid priority. 



Example ; Assume that lines A, B, and C are 
all sending messages to line D. 

Originating Arrival of Incoming Messages 
Line Time » t 

A A x @p Qi 

B B ± 

C C, 



Messages sent with priority are circled: 
the priority is indicated by superscript. 
Assume that by time "t", seven messages 
have arrived on the destination queue for 
line D in the order: A ± B ± A 2 C x A 3 B 2 C 2 . 
Since messages A 3 „ B 2 , and C 2 are the last 
messages received from their respective 
originating lines, only they will have 
priority. Thus, because priority message 
A 3 arrived on the destination queue before 
priority message A 2 (previously placed on 
the queue) was sent to D, message A 2 loses 
its assigned priority and is sent on a 
first- in-first-out basis like all other 
non-priority messages. If at time "t", 
message C 2 is sent, and a new priority mes- 
sage B 3 arrives on the queue before message 
B 2 is sent, B 2 loses its priority status to 
B 3 . Assuming no more messages arrive on 
the queue before all the priority messages 
are sent, the remaining messages on the 
queue are sent in the order: B 3 A 3 A ± B x 
A 2 Cj_ B 2 . 

Use of MODE is optional. If used,, it 
must appear in the Receive Header or Send 
Header subgroup of the LPS. It may be used 
more than once in either subgroup. Its 
position within the subgroup must corre- 
spond to the point during header processing 
at which the function designated by its 
operand is to be performed. 

The PRIORITY, CONVERSE, and INITIATE 
operands of the MODE macro instruction can- 
not be specified with the IBM 2740 Model 2. 

r — t t 

I Operation | Operand | 

h _ + .| 

PRIORITY N 
)CONVERSE| 
.INITIATE 
I MODE I /MOD2260 

luserf unc 

[,condchar] 

[,WRT60=code] 
l x . J 



PRIORITY 

causes scanning cf the header to lo- 
cate the next nonblank character. 
This character is the priority value 
of the incoming message. It must be a 
letter or a digit. The priority 
sequence is A„...Z,0...9 (9 is highest 
priority) . 



If MODE designates a specific charac- 
ter by means of the second operand, 
scanning of the header for a priority 
character occurs only when the charac- 
ter designated in the second operand 
is found. If no specific character is 
designated, scanning always occurs, 
and all messages must have a priority 
character as the next nonblank 
character. 

CONVERSE 

causes the line, on which the origina- 
ting terminal is located, to be placed 
in conversational mode. The line is 
held open until an entire message from 
that terminal has been received by a 
message processing program and that 
program has sent a response message to 
the same terminal. During this time, 
no incoming messages can be sent by 
any other terminal on the line, and 
outgoing messages that have been 
queued for sending to any terminal on 
the line will not be sent. The line 
will remain in ccnversational mode 
until a negative response is received 
from the terminal or until the termi- 
nal is allowed to time-out. If the 
message was sent from a terminal that 
was polled using the Auto Poll facili- 
ty, that terminal will remain in con- 
versational mode until the first reply 
is received from the message process- 
ing program. The second operand can 
be specified for conditional use of 
CONVERSE. Conversational mode will 
not be established with process queues 
that are not open. 

INITIATE 

causes segments cf a message to be 
sent from a destination queue to the 
destination as soon as they are placed 
on the queue (normally, segments are 
not sent to the destination until the 
complete message has accumulated on 
the queue). If a message has multiple 
destination codes specified in the 
header, the INITIATE function is per- 
formed only for the first destination. 
Sending to the remaining destinations 
will occur only after the complete 
message has been placed on the 
destination queue. Messages contain- 
ing an EOB character in initiate mode 
may not be sent to a terminal attached 
to a 2701 Data Adapter Unit. The 
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second operand can be specified for 
conditional use of INITIATE. 



This operand must be specified if and 
only if the MOD226 operand is specif ied. 



MOD2260 

causes QTAM to modify the Write opera- 
tion for IBM 2260s. The specific 
change is indicated by the WRT60 key- 
word operand of this macro. MOD2260 
may be specified only when the mode 
macro is included in the Send Header 
LPS subgroup. If this operand is not 
supplied, a Write DC (Display Control) 
function will be executed. 

userfunc 

the name of a routine provided by the 
user to perform a desired function. 
The routine must be in irain storage 
and in the same control section that 
contains the LPS section of the mes- 
sage control program. (See the sec- 
tion entitled Including a user-Written 
Subroutine Within the LPS.) 

condchar 

a character that,, if found in the 
header before another nonblank charac- 
ter, causes execution of the function 
specified by the first operand, 
"condchar" can be any single nonblank 
character. If this second operand is 
omitted, the function is performed 
unconditionally for all messages. The 
character may be specified either as 
the character itself , or as the hexa- 
decimal equivalent. 

WRT60 

specifies the type of modification to 
be made to the Write operation for the 
2260. 

WRT60=1 Causes erasure of the 2260 
screen before the next segment is 
displayed. 

WRT60=2 Causes a Write line address 
operation for the 2260. The user must 
specify the line address character as 
the first character of the header of 
the message to be written out, 

The user may cause the line address to 
be inserted by: 

1. Writing assembly language 
instructions to perform this in 
his LPS. 

2. Writing assembly language 
instructions to perform this in 
his message processing task.. 

3. Using the PAUSE macro. 

The EBCDIC and ASCII- 8 equivalents of 
each line address are given in Figure 15. 
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Figure 15. Line Address ASCII and EBCDIC 
Equivalents for IBM 226 

Message Type (MSGTYPE) Macro Instruction 



MSGTYPE enables the user to categorize 
incoming and outgoing messages into two or 
more message types, each of which he wishes 
to process in a different manner. A 
MSGTYPE macro instruction encountered dur- 
ing processing of a message header causes 
the next nonblank character in the header 
to be compared with a character specified 
by the operand of the MSGTYPE macro 
instruction. If the two characters are 
identical, the instructions between this 
MSGTYPE macro and the next MSGTYPE macro or 
the next delimiter macro instruction are 
executed. If the two characters are not 
identical, the instructions between the 
MSGTYPE macro performing the test and the 
next MSGTYPE macro or delimiter are not 
executed,, The scan pointer is reset to its 
position prior to the comparison. Instruc- 
tions between a MSGTYPE macro instruction 
with no operand and the next delimiter are 
executed for messages that do not contain a 
message-type character. The scan pointer 
is not advanced in this case. These 
instructions are bypassed if the message 
was previously handled by a MSGTYPE macro 
instruction with a message-type character 
operand. 

Use of MSGTYPE is optional. Any number 
of MSGTYPE macro instructions may be used 
within a subgroup,, provided that they all 
examine the same position in the header for 
a message-type character. Only one posi- 
tion in a header per Receive Header sub- 
group may contain a message-type character. 
KSGTYPE macro instructions may be used only 
within the Receive Header and Send Header 
subgroups. 
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typechar 

the message- type code. It may be any 
single nonblank character. If this 
operand is omitted (i.e..,, a blank is 
specified) , the group of macro 
instructions that immediately follows 
this MSGTYPE macro instruction will 
process any message not handled by a 
preceding MSGTYPE macro instruction 
with a nonblank character operand. If 
a MSGTYPE macro with a blank operand 
is used, it must be the last of the 
series of MSGTYPE macros. The 
message-type character may be speci- 
fied either as the character itself, 
or as the hexadecimal equivalent of 
the character. 

Example ; The beginning of a Line Procedure 
Specification section using MSGTYPE macro 
instructions is shown in Figure 16. 



of message traffic going to the control 
terminal, equal priority may make it 
extremely hard to enter a message from that 
terminal,. Once a polling pass has been 
completed, all messages to that terminal 
will be sent. This may keep the terminal 
permanently busy, not allowing any messages 
to be sent in.. If this situation is con- 
ceivable, then the responsibility should be 
split between the control terminal and the 
alternate. One terminal should be used 
solely to receive messages and the other 
solely to send them. If the control termi- 
nals are not being polled using the Auto 
Poll facility, then receive priority must 
be specified and there will be no problem 
in getting the messages into the system. 

Note ; Only one OPCTL macro may be issued 
in the message control program. The scan 
pointer must be positioned to the character 
before the control message identifier char- 
acters in the message header before issuing 
the OPCTL macro. 

If the telecommunications control termi- 
nal is to be polled using the Auto Poll 
facility,, then the SOURCE macro instruction 
must precede the OPCTL macro instruction. 



Operator Control (OPCTL) Macro Instruction 



The user may find it advisable to examine 
control information used by QTAM and to 
make necessary changes from an external 
source. QTAM provides an operator control 
facility to perform this function from a 
terminal, in addition to the macro instruc- 
tions described previously. 
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Operator control is specified by includ- 
ing an OPCTL macro instruction in the 
RCVHDR section of the LPS for the line 
group which contains the telecommunications 
control terminal. A local 1050 or a 2740 
with station control and checking must be 
provided for this function. 

Each operator control message is treated 
as a header segment and the complete mes- 
sage, including EOB and EOT characters, 
must fit in one buffer. If the data as 
transmitted from the terminal overflows the 
buffer, the message will be returned to the 
originating terminal, indicating an error. 
If the data to be sent to the terminal 
overflows the buffer, the excessive data 
will not be transmitted. 



name 



the name of the macro instruction. It 
must be the same as the OPCTL speci- 
fied in the TERMTBL macro instruction. 



CTLMSG=msgname 



msgname 

is the control message name iden- 
tifier, containing one to eight 
nonblank characters; it must be 
specified,. This name identifies 
a message as a QTAM control 
message. 



TERM=t ermname 



If the operator control facility is 
being used, receiving must have priority 
over sending on the line containing the 
telecommunications control terminals. If, 
however, the control terminals are being 
polled using the Auto Poll facility, then 
equal priority must be specified. With 
large systems that will have a great deal 



termname 

is the name of the telecommunica- 
tions system control terminal as 
it appears in the TERM entry for 
this terminal. This terminal may 
be a nonswitched 1050 or non- 
switched 2740 with Station 
Control. 
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Name | Operation | Operand | Comments 

4. _ _L i— _ _ _ _ _ 


T T 1 

LPS1 | LPSTART | 15, TERM= (1050) | Reserve 15 bytes in header 
+ 4 4 

| RCVSEG | | Delimiter 
+ 4 4 

| TRANS |RCVET1 | Macro instruction executed for all segments 
4 + 4 

| RCVHDR | | Delimiter 
4 4 4 

| SEQIN |4 | 

j SOURCE |3 j Macro instructions executed for all header segments 
| DATESTMP | | 
j TIMESTMP |8 j 

| COUNTER |MSGIN j Count number of incoming messages 
4 + 4 

i MSGTYPE |C'A" | Test for type A messages 
+ + 4 

| - | | Macro instructions executed for all type A messages 

| DIRECT |=CL8'CHI' | 
+ 4 + 

j MSGTYPE IC'B* | Test for type B messages 
4 4 + 

| - | | Macro instructions executed for all type B messages 
j DIRECT |=CL8'NYC' | 

._ _L _ _ J. _ J _ _ _ _ _ _ _ _ _ 


T T 1 

| MSGTYPE | | Test for all other message types 

4 4 4 

| DIRECT |=CL8'PROCESSQ' | Macro instruction executed for all other message 
I I I types 

4 4 4 

| ENDRCV | | Delimiter 
4 4 4 

j - | j Remaining macro instructions of LPS 



U X 

Figure 16. Use of 



-X x 

MSGTYPE Macro Instruction in an LPS 



ALTERM=termname 



termname 

if specified, is the name of an 
alternate telecommunications sys- 
tem control terminal as it 
appears in the TERM entry for 
that terminal. Control messages 
may be entered froir this terminal 
or the primary. This terminal 
may be a nonswitched 1050 or non- 
switched 2740 with Station 
Control. 

Restriction : Messages from this 
terminal must be processed by the 
same LPS that includes the OPCTL 
macro instruction. 



INTRCPT 



INTRCPT=YES must be specified if 
INTERCPT or RELEASEM operator 
control messages are to be 
accepted from the telecommunica- 
tions control terminal. In addi- 



tion, there must be a 3-byte 
OPTION field labeled INTERCPT 
defined for the terminal table 
entries. 

If INTRCPT=NO is specified, or if 
this operand is omitted, INTERCPT 
and RELEASEM operator control 
messages will not be accepted. 

Example: 

r t t 1 

| Name | Operation | Operand | 

j. 4 4 i 

j OPCTLNME | OPCTL j CTLMSG=QCTL„ TERM=LOCAL | 

L X X J 



PAUSE Macro Instruction 



PAUSE causes automatic transmission of a 
user-specified sequence of characters on 
the communication line each time the LPS 
section containing the PAUSE encounters a 
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user-specified character in the message 
segment currently being sent. The inserted 
characters are not placed in the outgoing 
message segment as contained in main 
storage. Rather, they become part of the 
segment as received at the terminal. To 
illustrate: If a message segment contain- 
ing the characters 

ABCDEF*GHI*ABCD*MNOPQ*RSTU**ABC 

is handled by an LPS in which a PAUSE macro 
specifies insertion of the characters XY 
each time an asterisk is encountered, the 
segment as contained in main storage 
remains unchanged, but as received by the 
destination terminal becomes 

ABCDEF*XYGHI*XYABCD*XYMNOPQ 
*XYRSTU*XY*XYABC 

This facility has two main uses: 

1. It permits the user to effectively 
modify outgoing message headers by 
inserting extra characters. The need 
for this arises when message headers 
received from certain terminal types 
are to be sent to other terminal 
types. In certain instances,, extra 
control characters must be sent on the 
line during transmission of the head- 
er, in order for the message to be 
received properly. 

2. It permits sending of nonprinting idle 
characters over the comirunication 
line, where necessary to prevent loss 
of message data. 

Characters in outgoing messages are sent 
continuously, even while the terminal 
device receiving the message is performing 
a mechanical positioning operation that 
interferes with correct recording of the 
incoming characters. For example,, some 
terminal printers require more time for the 
carriage return operation than is available 
between printing of successive message 
characters; characters are printed during 
the carriage return movement. 

To avoid partial loss of a message from 
this cause, one or more nonprinting charac- 
ters must be inserted into the message 
after each device control character (such 
as carriage return) that performs an opera- 
tion otherwise resulting in loss of message 
characters. These nonprinting characters 
are referred to as idle characters, 
although tne specific character to be used 
depends on the type of terminal that 
receives the message. The idle characters 
used by each type of device are shown in 
Figure 17. 

The PAUSE macro can be used to cause 
insertion of idle characters each time a 



designated device control character appears 
in the message. (Device control characters 
can be inserted by a user-provided subrou- 
tine or by the teririnal that originates the 
message.) The specific control characters 
for which insertion is required,, and the 
number of idle characters required for 
each, vary among terminal device types. 
For these requirements, see the reference 
manuals for the various terminal types. 

The PAUSE macro instruction specifies: 

1. The character that is to cause 
insertion. 

2. The number of character sequences to 
be inserted. 

3. The transmission code bit configura- 
tion of the characters to be inserted. 

A separate PAUSE macro instruction must 
be specified for each control character for 
which insertion is required. 

PAUSE cannot be used to cause the EOB 
character to be transmitted. 

PAUSE* if used, must appear within the 
Send Header or Send Segment subgroups. 

r t i 

| Operation | Operand | 

L 4 < 

I ] PAUSE | ctlchar,msertchar | 

I i x J 

ctlchar 

the actual transmission code bit con- 
figuration of the character for which 
insertion is required if TRANS pre- 
cedes PAUSE, and the EBCDIC code bit 
configuration if PAUSE precedes TRANS. 
It must be written in hexadecimal 
notation. This cannot be the EOB 
character. 

insertchar 

the actual transmission code bit con- 
figuration of the character (or char- 
acters) to be inserted. It must be 
written in hexadecimal notation, in 
the form nX'hexchars' , where "n" is 
the number of character sequences to 
be inserted. (For example, 5X'E2E4' 
specifies that the sequence AB [in 
1050 code] is to be sent five times.) 



Example : A PAUSE macro instruction to 
cause insertion of six idle characters into 
an outgoing message tc an IBM 1050 each 
time a new line (NL) character is detected 
in that message by the message control pro- 
gram (5B and 5E are hexadecimal equivalents 
of 1050 transmission code new line and idle 
characters, respectively) : 
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r t 

| Operation | Operand 



PAUSE 



X'5B' ,6X'5E* 



r t 

| Terminal Type | Idle Character and Code 



I- 

|IBM 1030, 1060 

I 

JIBM 1050, 2740 

I 

| AT&T 33, 35 
I (TWX) 

I 

| AT&T 83B3, 
jWU 11 5A 

I 
IWTTA 



Idle (5E) 

Idle (5E) or delete (7F) 

Rubout (FF) 

Figures shift (IB) 
or letters shift (IF) 

Figures shift (IB or 3B) 
Letters shift (IF or 3F) 
or Mark (DF) 



Figure 17. Idle Characters 



25 5, Leading zeros may not be speci- 
fied in this operand. 

subf ield 

the name of an optional subfield in a 
terminal table entry. It must be the 
same as the name assigned to the sub- 
field by an OPTION macro instruction. 
This subfield contains the limit of 
consecutive polls to be allowed for 
the originating terminal, as specified 
by a TERM macro instruction. This 
method of specifying the polling limit 
allows a different limit to be set for 
each terminal. 



REROUTE Macro Instruction 



REROUTE causes a message to be queued for 
an alternate destination (in addition to 
the destinations specified by the message 
header) when any of the errors specified by 
the mask has been detected. 



Polling Limit (POLLIMIT) Macro Instruction 



POLLIMIT is an optional macro instruction 
specifying a maximum number of messages to 
be accepted from a nonswitched terminal 
during one polling pass. When this limit 
is reached, the next terminal is polled. 
If no polling limit is set (that is, the 
POLLIMIT macro instruction is not used) , 
each terminal is polled until it has no 
more messages to send during that polling 
pass. 

The POLLIMIT macro instruction has no 
effect when used with a switched line, and 
is not applicable to WTTA lines. 

If used,, POLLIMIT must appear at some 
point within the Receive Header or End 
Receive subgroup. 

Note : For an IBM 2260, the LPS must 
include POLLIMIT, a macro that specifies a 
polling limit of 1,. 

r t 1 

| Operation | Operand | 

l + ., 

| POLLIMIT | fnnn \ | 

| | \ subfield j | 



nnn 



the maximum number of messages the 
user wishes to allow for each terminal 
in the line group. This option may be 
used only when the number cf consecu- 
tive polls is to be the same for all 
terminals in the communication line 
group. The maximum value of "nnn" is 



The meaning of the bits in the error 
half word tested is shewn in Figure 14. 

If the destinations specified by the 
message header are switched terminals, the 
SOURCE macro instruction must appear in the 
LPS prior to REROUTE, in order for the 
"subfield" operand to be specified, A dis- 
tribution list entry cannot be specified as 
the alternate destination. 

Use of REROUTE is optional. If used, it 
must appear in the End Receive or End Send 
subgroup. 



Restriction ; REROUTE must not be used for 
any message whose destination is a process- 
ing program queue identified by a PROCESS 
EXPEDITE terminal table entry. 



r t 

| Operation J Operand 

h 



REROUTE 



mask, 

=CLn*dest* 

subfield 

SOURCE 



mask 



dest 



the hexadecimal representation of the 
bit configuration used to test the 
error halfword in the line control 
block (LCB). 



the destination code for the alternate 
destination. The code may be the name 
of any entry that appears in the ter- 



84 



minal table. If this option is 
selected,, all messages from any line 
in the line group with errors detected 
by REROUTE are sent to the same 
destination. "n" must be equal to or 
greater than the longest destination 
name appearing in the terminal table; 
the maximum value for "n" is 8. 

subf ield 

the name of an optional subfield in 
the terminal table that contains the 
name of the alternate destination. 
The name must be the same as the name 
assigned to the subfield by an OPTION 
macro instruction. If this option is 
selected, the alternate destination is 
the terminal specified in the option 
field of either 

1. the terminal table entry for the 
originating terminal, if REROUTE 
is used in the ENDRCV section of 
the LPS, or 

2. the terminal table entry for the 
destination terminal, if REROUTE 
is used in the ENDSEND section of 
the LPS. 

For example, in Figure 10, alternate 
destinations are specified in the third 
OPTION field in the terminal table entries. 
If a message was received from WAS and 

REROUTE DEST 

was coded in the ENDRCV portion of the LPS, 
then the message would be sent to NYC also. 

SOURCE 

specifies that the error message con- 
taining the error is to be sent to the 
terminal from which it originated (in 
addition to the destinations specified 
by the message header) . 



Routing (ROUTE) Macro Instruction 



ROUTE causes scanning of the destination 
code field in the header of each incoming 
message. If the destination code is valid, 
ROUTE causes the message to be queued for 
the specified destinations. If an invalid 
destination code (i.e., one not appearing 
in the terminal table) is detected: 



1. Bit of the error halfword for the 

line containing the originating termi- 
nal is set to 1. 



If further processing of messages placed 
on the dead-letter queue is required, a 
REROUTE or ERRMSG macro instruction must be 
specified in the End Receive subgroup to 
notify a terminal operator of the destina- 
tion error. 

Messages may be routed to multiple 
destinations in any of three ways : 

1. More than one destination code may be 
included in the message header. It is 
not necessary to indicate in the head- 
er the number of destination codes 
included. When this method of routing 
to multiple terminals is used, the 
user must: 

a. Include an end-of -address (EOA) 
character after the last destina- 
tion code in the header of each 
incoming message (see EOA macro) . 

b. Specify an EOA macro instruction 
immediately following ROUTE in the 
LPS. 

2. The message header may contain a 
single destination code that identi- 
fies a distribution list entry in the 
terminal table. Each destination in 
the distribution list receives the 
message. 

3. Where special machine features are 
available, "group code" transmission 
may be used. Under this method, 
unique address characters cause the 
sending of single messages simul- 
taneously to a prespecified group of 
terminals on the same line. 

Either the ROUTE or the DIRECT macro 
instruction must be specified to handle 
message routing. Both cannot be used for 
the same message type. Only one ROUTE 
macro may be used for each LPS or for each 
message type used within one LPS (see the 
NSGTYPE macro instruction description) . 
ROUTE may be used only within the Receive 
Header subgroup. 

Note : If the POLL macro instruction speci- 
fies that the IBM 2260-2848 complex is to 
be polled using the general poll feature, 
the DIRECT macro instruction must be used. 
ROUTE cannot be specified. 

r r 1 

| Operation] Operand j 

L + i 

I | ROUTE j [n] | 

• L JL J 



2. The message is placed on the dead- 
letter queue. (The dead- letter queue 
is generated by QTAM on the direct 
access device.) 



the number of characters in each 
destination code in the message head- 
er, "n" is specified only if the user 
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chooses to make all destination codes 
the same length. The maximum value of 
"n" is 8. If this operand is omitted,, 
destination codes are assumed to have 
varying lengths and a blank is 
required: 

1. After a single destination code. 

2. Between multiple destination 
codes.. 

3. Between the last destination code 
and the EOA character. 

If "n" is specified, the blanks are 
not required. 



r t t 

| Operation | Operand | 

j. + .| 

J SEQIN j Cn] | 

L i J 



n 



the number of character positions in 
the header field for the input-message 
sequence number. The maximum value of 
"n" is i). If this operand is omitted, 
a variable- length field is assumed. 
In this case, the input-message 
sequence number must be followed by a 
blank used as a field delimiter. The 
value "n" does not include any blanks 
preceding or following the sequence 
number digits. 



Sequence In (SEQIN) Macro Instruction 



SEQIN causes scanning of the input sequence 
number field in the header of each incoming 
message. If the sequence nuirber is not one 
higher than the sequence number of the last 
message received from the sending terminal, 
an error flag is set in bit 2 or bit 3 
(depending on whether the number is high or 
low) of the error half word for the line. 

The first message from a terminal must 
contain the same input sequence number as 
the TSEQUIN field of the terminal table 
entry for that terminal. QTAM initially 
sets TSEQUIN to 1. The user may at any 
time reset (by means of the STOPLN and 
CHNGT macro instructions) the contents of 
TSEQUIN. If TSEQUIN is reset before the 
maximum number (9999) is reached, the next 
incoming message must have the same number 
as TSEQUIN. If TSEQUIN is not reset before 
the maximum number is reached,, the next 
incoming message after 9999 irust be num- 
bered 0000. 

In general, SEQIN causes the input 
sequence number field in the terminal table 
entry to be incremented for each message 
having a correct input sequence number in 
the header. If, however, CANCELM causes a 
message in error to be cancelled, or if an 
EOBLC macro causes retransmission of the 
first block of a message, the input 
sequence number is not incremented. In the 
latter case, the number is incremented when 
the first block is successfully 
retransmitted . 

Use of SEQIN is optional. For switched 
terminals, the SEQIN macro instruction, if 
used, must be preceded by a SOURCE macro 
instruction. SEQIN may be used only within 
the Receive Header subgroup. Its position 
must correspond to the position of the 
sequence number field relative to other 
header fields,. 



Sequence Out (SEQOUT) Macro Instruction 



SEQOUT is used to place an output sequence 
number in the header of each outgoing mes- 
sage. The LPS maintains a separate 
sequence count for each terminal and each 
terminal group (where group code addressing 
is used) . Each message for the terminal or 
terminal group is given a sequence number 
one greater than that of the preceding mes- 
sage for the same terminal or group. 

A message in error rerouted via a 
REROUTE macro or resent by the EOBLC macro 
retains the output sequence number origi- 
nally placed in it by the LPS. 

Use of SEQOUT is optional. If used w it 
may appear within the Receive Header or 
Send Header subgroup. Its position must 
correspond to the relative position, within 
the header, of the field into which the 
sequence number is inserted. 

If SEQOUT is used in the RCVHDR section 
of the LPS„ it must appear following a 
ROUTE or DIRECT macro specifying a process 
queue. If SEQOUT is used with either the 
time stamp or date stamp facility, SEQOUT 
must be specified after the TIMESTMP and/or 
DATESTMP macro instructions. When used in 
the RCVHDR section, all incoming header 
segments routed to a message processing 
program will be assigned an output sequence 
number. This sequence number is two bytes 
long and will be inserted wherever the scan 
pointer is pointing when SEQOUT is issued. 
By inserting the output sequence number in 
messages sent to queues for message pro- 
cessing programs, the capability is 
included to allow these programs to check 
for lost messages. For example, if there 
are three message processing programs, in a 
telecommunications system, three separate 
counters will be kept, one for messages for 
each processing program queue. If message 
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processing program A receives the message 
with output sequence number 4, followed by 
the message with output sequence 6, then 
that program has the capability to tell 
that message 5 is missing. The message 
control will not check this field in any 
way- However, this sequence number must be 
removed by the processing program before 
the message is put to a terminal destina- 
tion. Otherwise, invalid characters may 
appear in a message header. 

When SEQOUT is specified, the user 
includes the value of "n" in his calcula- 
tion of the operand value of the LPSTART 
macro instruction (see the LPSTART macro 
instruction description) . 



skipchars 

designates the number of nonblank 
characters to be skipped, or the actu- 
al characters in the sequence that is 
to terminate the skip operation. The 
number of characters to be skipped is 
specified as "n", and cannot exceed 
the number of characters remaining in 
the header. The character sequence 
may be specified as the characters 
themselves or as the hexadecimal 
equivalent. The sequence may be 1 to 
8 nonblank characters. The framing C 
or X and quotes must be coded. 

Example: A SKIP macro instruction to cause 
skipping of five characters: 



r t ' 1 

| Operation | Operand | 

j. + ___ ^ 

j SEQOUT | [n] | 

L X J 



r t 1 

| Operation] Operand | 

V x .| 

| SKIP J 5 | 

L X J 



the number of characters to be 
inserted in the header for the output 
sequence number. The first character 
is always a blank. Therefore "n" must 
be specified as the number of 
sequence-number digits plus 1 . The 
maximum value of "n" is 5 (that is, 
the maximum field size is five charac- 
ters, allowing for a sequence number 
range between 0001 and 9999). When 
the last available sequence number 
(99, 999, or 9999) has been issued to 
a message, the numbering cycle is 
repeated. The next message is num- 
bered 0000. 



Example : A SKIP macro instruction to skip 
characters up to and including #= may spec- 
ify the characters themselves, or the hexa- 
decimal representation of the characters. 

r t u 

| Operation | Operand | 

j. x .] 

JSKIP | C f #=' j (1) 

jSKIP j X'7B7E" j (2) 

L X J 



SOURCE Macro Instruction 



SKIP Macro Instruction 



SKIP causes skipping of either a designated 
number of nonblank characters, or all char- 
acters up to and including a designated 
sequence of characters. The sequence may 
consist of 1 to 8 nonblank characters. 
This permits the user to skip fields in the 
message header during processing. One SKIP 
macro instruction is specified for each 
field to be skipped. SKIP macro instruc- 
tions must appear among other functional 
macro instructions in the sarre relative 
order as fields to be skipped appear among 
other header fields. 

Use of SKIP is optional. It may be used 
only within the Receive Header and Send 
Header subgroups. 

r t 1 

| Operation | Operand | 

K x .j 

| SKIP | skipchars | 

L X J 



The SOURCE macro instruction causes scan- 
ning of the source terminal code field in 
the header of each incoming message to 
determine if the source code is valid. The 
validity check performed varies „ depending 
on whether the source terminal is on a non- 
switched or a switched line. 

If the source terminal is on a non- 
switched line, SOURCE verifies that the 
header contains the symbolic name of the 
same terminal that was invited to send a 
message (that is,, the source code field in 
the header is compared with the name of the 
terminal table entry for the terminal that 
was polled). If the names are not equal,, 
an error flag is set in bit 6 of the error 
halfword for the line. (See Figure 14.) 

If the source terminal is on a switched 
line or an Auto Poll line, SOURCE can only 
verify that the source code field in the 
header contains a valid name (the name of 
an entry in the terminal table, but not 
necessarily the name of the entry for the 
terminal that was polled) . If a name that 
does not appear in the terminal table is 
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detected, an error flag is set in bit 6 of 
the error half word. 

Use of SOURCE is required if: 

1. It is desired to transmit messages 
queued for a switched terminal when- 
ever that terminal initiates contact 
with the CPU. This capability 
requires no new connection. 

2. It is desired to use the SOURCE 
operand in an ERRMSG macro instruction 
in an LPS for switched lines. 

3. The SEQIN or COUNTER macro instruction 
is used in the Receive Group of the 
LPS for switched terminals or for ter- 
minals on an Auto Poll line,, or 

4. The DIRECT, ERRMSG, POLLIMIT, or 
REROUTE macro instruction containing 
the "subfield" operand is used in the 
Receive Group of the LPS for switched 
terminals or for terminals on an Auto 
Poll line. 

In either case, SOURCE must precede 
the above macros in the LPS.. 



In this case, the source terminal code 
must be followed by a blank used as a 
field delimiter. 



Time Stamp CTIMESTMP) Macro Instruction 



TIMESTMP causes insertion of the time of 
day into the header portion of a message - 
This function can be specified for incoming 
messages, outgoing messages, or both. The 
time is expressed in the form bhh.mm.ss, 
where b is a blank, hh is the hours, mm the 
minutes, and ss the seconds. Nine charac- 
ter positions are required for the complete 
time information. However, the user may 
provide a shortened form (for example, omit 
the seconds) by reserving fewer than nine 
positions in the message header. 

Use of TIMESTMP is optional. If used, 
it must appear in the Receive Header or 
Send Header subgroup. Its position within 
the subgroup must correspond to the rela- 
tive position, within the header,, of the 
field into which the time of day is 
inserted. 



5. The Auto Poll facility or switched 
line groups are used and the TRMAD 
parameter is used in the DCB for the 
main storage process queue in the mes- 
sage processing program. The use of 
SOURCE is required to get the symbolic 
name of the source terminal. When a 
GET is executed to get a record from 
the MS process queue, this source name 
is placed at the address specified in 
TRMAD. (See the discussion of the DCB 
for Main Storage Process Queue in the 
QTAM Message Processing Program Ser- 
vices publication. ) 

5 . The terminal does not have the Auto 
Answer facility or CALL=NONE in the 
TERM macro. 

SOURCE may be used only within the 
Receive Header subgroup. Its position 
within the subgroup must correspond to the 
position of the source terminal code field 
relative to other header fields. 



When TIMESTMP is specif ied„ the user 
includes the value of "n" in his calcula- 
tion of the value of the operand of the 
LPSTART macro instruction (see the LPSTART 
macro instruction description). 

Restriction : TIMESTMP may be used only 
when the operating system includes the 
timer capability (option 6A) . 

r t t 

| Operation) Operand | 

L 1 -, 

I j TIMESTMP \ n | 

I L J. J 



the number of characters of time-of- 
day information to be inserted in the 
header portion of each message. The 
maximum value of "n" is 9, and the 
value specified reflects the presence 
of the leading blank in the time 
information. 



r t — • 1 

| Operation] Operand | 

j. + ^ 

j SOURCE | [n] j 

L ; J. : J 



the number of characters in the source 
terminal code field of the message 
header. The maximum value of "n" is 
8. If this operand is omitted, a 
field of variable length is assumed. 



Translate (TRANS) Macro Instruction 



TRANS causes the characters of an incoming 
or outgoing message to be translated from 
one code to another,. Incoming messages 
from a terminal are translated from the 
transmission code for that terminal type to 
EBCDIC. Outgoing messages are translated 
from EBCDIC to the transmission code for 
that terminal type. Translation is done 



character for character. TRANS specifies 
the transmission code from which or into 
which the message is to be translated. 

TRANS is normally required in an LPS. 
TRANS may be used in the Receive Header 
and/or Send Header subgroups to translate 
only the headers of incoming and outgoing 
messages, respectively (message switching 
to same terminal type) . TRANS may be used 
in the Receive Segment and/or Send Segment 
subgroups to translate all segments includ- 
ing header segments, of incoming and outgo- 
ing messages, respectively (inquiry pro- 
cessing and collection of data that is to 
be processed at a later time) . 

TRANS must not be used in the Receive 
Header subgroup if EOB or EOBLC is used in 
the End Receive subgroup. Similarly,, TRANS 
must not be used in the Send Header sub- 
group if EOB or EOBLC is used in the End 
send suogroup. 

TRANS is not required in a message 
switching application in which no analysis 
of the header is required of QTAM, provided 
that: 

1. The originating and the destination 
terminals are of the same type. 

2. The DIRECT macro, rather than the 
ROUTE macro, is used to send messages 
to destination terminals. 

Code translation is normally accom- 
plished through tables provided by QTAM,, 
although the user may prepare and use his 
own tables, if desired. For each terminal 
type, QTAM provides two tables: one to 
translate from transmission code to EBCDIC, 
and one to translate from EBCDIC to trans- 
mission code. 

All of the characters in the character 
sets of each of the types of terminals ca- 
pable of communicating with the System/360 
CPU can be represented within the computer. 
However, some characters valid for one type 
of terminal device may not be valid for 
another type of terminal device. In a mes- 
sage switching application in which mes- 
sages are exchanged between dissimilar ter- 
minal devices, the user should either: 

1. Avoid placing in the message any char- 
acters that are not recognized by the 
destination terminal . 

2. Employ a user -written translation 
table that converts such characters to 
other characters that are acceptable 
to the destination terminal. 

The character sets of the IBM 1050 and 
IBM 2740 contain lowercase as well as 
uppercase alphabetic characters. When mes- 



sages from an IBM 1050 or 2740 are sent to 
terminal devices or processing programs 
that do not recognize codes for lowercase 
characters, the user should either: 

1. Use only the uppercase form of alpha- 
betic characters. 

2. Employ the RCVF1050 (or RCVF2740) 
translation table (or the user's equi- 
valent). The RCVF1050 and RCVF2740 
tables translate each incoming lower- 
case letter to the EBCDIC representa- 
tion of that letter's uppercase equi- 
valent. Messages sent by an IBM 1050 
or 2740 may contain lowercase and 
uppercase letters. However* messages 
received by an IBM 1050 or 2740 from a 
device or a processing program incap- 
able of sending lowercase characters 
will contain only the uppercase form 
of alphabetic characters. 

Note : All terminal table entry names are 
assembled into the terminal table as upper- 
case EBCDIC characters,. In order for 
source and destination code information in 
message headers to be recognized by the LPS 
as valid, such information must also appear 
to the LPS in uppercase EBCDIC form. For 
this reason, source and destination codes 
entered into message headers at an IBM 1050 
or 2740 must be entered in uppercase form, 
if the RCVE1050 or RCVE2740 translate 
tables are used. They may be entered in 
uppercase or lowercase, if the RCVF1050 and 
RCVF2740 tables are used. 

There are two types of TWX terminals 
that may be used with QTAM. The first type 
will accept parity data from the CPU. For 
this type of TWX, the SENDT2 translation 
table is provided. The second type will 
accept only nonparity data from the CPU 
(the parity bit must be 1 in all charac- 
ters) . The SENDT3 translation table is 
provided for translation of data sent to 
these TWX terminals. The user may wish to 
have both types of TWX terminals in the 
same line group, in which case he must pro- 
vide both the SENDT2 and SENDT3 forms of 
the TRANS macro in the same LPS. It is the 
user's responsibility to execute the appro- 
priate TRANS macro and branch around the 
inappropriate one, depending upon the type 
of TWX terminal he is sending the message 
to. QTAM will not perform this function. 

The SEND226 translate table converts 
lowercase alphabetic characters to upper- 
case so that the terminal receives only 
uppercase characters. 

r t 1 

| Operation | Operand | 

L + < 

I] TRANS ] table j 

• i x J 
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For WTTA terminals,, two codes can be 
used with QTAM: International Telegraph 
Alphabet no. 2 (ITA2), and Figure Protected 
Code ZSC3 (ZSC3). Four translation tables 
are provided (two per 5- level code used). 
The user can modify these tables by using 
the four WTTA macro instructions RCVEITA2, 
RCVEZSC3, SENDITA2, and SENDZSC3. 



table 



the name of the code translation 
table. Names of tables provided by 
QTAM are given in Figure 18. 



Example ; A TRANS macro instruction to 
translate messages sent from an IBM 1030 to 
the computer: 

r t 1 

| Operation | Operand | 

y + i 

J TRANS | RCVE1030 j 

L x J 

Example : A TRANS macro instruction to 
translate messages from the computer to an 
AT ST 83B3 terminal: 

r t t 

| Operation | Operand | 

y + ., 

| TRANS | SENDT1 j 

I X J 



WRU Macro Instruction 



To request an identification exchange dur- 
ing transmission of an output message, a 
WRU macro instruction must be written in 
the Send Header and/or the End Send sub- 
groups of the LPS. If the identification 
sent by the terminal is not the same as 
that specified by the ID parameter in the 
corresponding TERM macro instruction, the 
transmission error bit (bit 8) and the 
message-not-sent bit (bit 12) of the error 
half word are set as follows: 

• Bit 8 is always set on. 

• Bit 12 is set on only when an identifi- 
cation exchange has been requested by a 
WRU macro instruction written in the 
Send Header subgroup of the LPS. 

The WRU macro instruction requires no 
operands and is effective provided either 
WRU=YES or IAM=YES is specified in the 
corresponding DCB macro instruction. 

r — ; t t 

| Operation | Operand | 

y + ,| 

| WRU j j 

L X J 



MODIFYING WTTA TRANSLATION TABLES 



Because the International Telegraph Alpha- 
bet No. 2 and the Figure Protected code 
ZSC3 vary with countries* tables RCVEIAT2,, 
RCVEZSC3, SENDITA2, and SENDZSC3 may not 
fit a particular application. Therefore, 
four macro instructions are provided to 
modify these tables,, when necessary, and 
thus produce new tables (WTTA translation 
tables) which can be used by the TRANS 
macro instruction. These four macro 
instructions are applicable to WTTA termi- 
nals only. They have the same names as the 
translation tables mentioned above, and 
they can be placed anywhere in the message 
control program. 



RCVEIAT2 and RCVEZSC3 Macro Instructions 



T T T 

Name | Operation | Operand | 
x + j 

symbol |RCVEITA2 ] {Fx=hexchar, } | 

X X ■. J 

t t n 

Name ] Operation J Operand | 
x x 1 

symbol j RCVEZSC3 j {Fx=hexchar„ } . . . j 

X X J 

where : 

symbol 

is the name of the translation table 
used in the TRANS macro instruction. 

RCVEITA2 

specifies that table RCVEITA2 is to be 
modified and assembled. 

RCVEZSC3 

specifies a modification to the table 
concerned. 

Fx=hexchar 

"F" means figure shift. 

"x" is the nuirber of the code combina- 
tion to be translated. 

"hexchar" is the hexadecimal represen- 
tation of this character in EBCDIC. 

The permissible values of "x" are: 

For RCVEITA2 : 1, 2„ 3, 6, 7, 8, 10 
through 14, 19, 24, 26, and 32. 

For RCVEZSC3: 1, 5, 8, 9, 11, 12, 14, 
15, 17 through 20, 22, 24, 26, and 32. 
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| Table Name 


Type of Conversion 


1 


Type of Terminal 


L 1 




i 






r — — t 


1 






| For incoming 




1 






j messages : 




1 






| RCVE1030 


1030 code to EBCDIC 


] 


IBM 1030 




j RCVE1050 


1050 code to EBCDIC 


1 


IBM 1050 




| RCVF1050 


1050 code to EBCDIC (converts 
lowercase alphabetic 
characters to uppercase) 


\ 
I 

1 


IBM 1050 




| RCVE1060 


1060 code to EBCDIC 


1 


IBM 1060 




j RCVE2260 


2260 code to EBCDIC 


] 


IBM 2260 




j RCVE2740 


2740 code to EBCDIC BCD code 


1 


IBM 2740 




| RCVF2740 


2740 code to EBCDIC 


1 








only 


1 


IBM 27 40 






(converts lowercase 


1 








alphabetic characters to 


1 








uppercase) 


1 






| RCVET1 


5-level (Baudot) code to 
EBCDIC 


1 
1 


AT&T 83B3, 


WU 11 5A 


| RCVET2 


8-level TWX code to EBCDIC 


] 


AT&T 33/35 


(TWX) 


| RCVEITA2 


5-level International Telegraph 
Alphabet No. 2 to EBCDIC 


1 
1 


WTTA 




| RCVEZSC3 


5-LEVEL Figure Protected Code 
ZSC3 to EBCDIC 


1 


WTTA 




L _ _ _ _ 


L _ _ 


1 






r — 1 


r 


9 






| For outgoing 




1 






j messages: 




3 






j SEND1030 


EBCDIC to 1030 code 


1 


IBM 1030 




j SEND1050 


EBCDIC to 1050 code 


1 


IBM 1050 




| SEND1060 


EBCDIC to 10 6 code 


1 


IBM 1060 




| SEND2260 


EBCDIC to 22 60 code 


1 


IBM 2260 




j SEND2740 


EBCDIC to 274 code 


] 


IBM 27 40 




| SENDT1 


EBCDIC to 5-level (Baudot) 
code 


1 
1 


AT&T 83B3, 


WU 11 5A 


| SENDT2 


EBCDIC to 8-level TWX code 


1 


AT&T 3 3/35 


TWX (parity) 


j SENDT3 * 


EBCDIC to 8-level TWX code 


I 


AT&T 33/35 


TWX (nonparity) 


| SENDITA2 


EBCDIC to 5-level International 
Telegraph Alphabet No. 2 


1 
1 


WTTA 




| SENDZSC3 


EBCDIC to 5-level Figure Pro- 
tected Code ZSC3 


3 

1 


WTTA 





Figure 18. Names of Code Translation Tables Provided by QTAM 



Example ; If a terminal operates in 5-bit 
International Telegraph Alphabet No. 2, 
combination no. 6 in figure shift repre- 
senting the % character does not exist in 
table RCVEITA2. The user must create the 
required WTTA translation table (TBL) by 
writing : 

TBL RCVEITA2 F6=6C 

where 6C is the hexadecimal representation 
of the X character in EBCDIC. 



SENDITA2 and SENDZSC3 Macro Instructions 



r t t 1 

| Name (Operation | Operand | 

t + + -I 

| symbol JSENDITA2 |{Xyy=Fx f } j 

L X 1 ,. J 



J Name j Operation | Operand 

j. + + 

] symbol j SENDZSC3 J {Xyy=Fx„ } . . 

L ± X 



where : 

symbol 

is the name of the translation table 
used in the TRANS macro instruction. 

SENDITA2 

specifies that table SENDITA2 is to be 
modified and assembled. 

SENDZSC3 

specifies that table SENDZSC3 is to be 
modified and assembled. 

Xyy=Fx 

Specifies a modification to the table 
concerned. 
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"X" is coded as shown. 

"yy" is the hexidecimal representation 
in EBCDIC of the character to be 
translated. 

"F" means figure shift. 

"x" is the number of the code combina- 
tion to be translated.. 

The permissible values of "yy" are: 

2A, 3F, Hh through 50, 5A through 61, 
6A through 6F, 7A through 7F. 

Example : If a terminal operates in 5-bit 
International Telegraph Alphabet No. 2 and 
if the user wishes to assign the hexadeci- 
mal value X'6C (% character in EBCDIC) to 
combination no. 6 in figure shift (% char- 
acter to be sent by the terminal), the 
required WTTA translation table (TBL) will 
be produced by writing : 

TBL SENDITA2 X6C=F6 

In the same way, the user can decide that 
the asterisk character CX'SC* in EBCDIC) is 
to be sent as a % character. The required 
WTTA translation table (TBL) will be pro- 
duced by writing : 

TBL SENDITA2 X5C=F6 

And if the user decides that both the % and 
the asterisk characters (X'6C and X'5C in 
EBCDIC, are to be sent as a % character, he 
will write: 



Note: 



TBL SENDITA2 XbC=F6 , X5C=F6 



One of these four macro instructions 



can be used to create several translation 
tables in the same program, provided that 
these tables are given different names. 
This enables several terminals, using the 
same codes but with differences in their 
graphic arrangements, to operate in the 
same installation. 



INCLUDING A USER-WRITTEN SUBROUTINE WITHIN 
THE LPS 



QTAM provides for the serial execution of a 
user-written subroutine within an LPS line 
group routine. The user-written code can 
be included as either an open or closed 
subroutine. 

There are several reasons why the user 
might include such a subroutine. There may 
be no IBM-provided LPS subroutine to pro- 
cess particular information he wishes 
included in his message headers. Or, he 



may wish to expand the scope of an IBM- 
provided LPS subroutine (for example, to 
execute error correction routines after the 
ERRMSG macro generated subroutine indicates 
an error) . A third case might be process- 
ing a header field in a manner entirely 
different from the way the IBM-provided LPS 
subroutine handles fields of this type. An 
example of this is inserting a date in a 
format different from the one used by the 
DATESTMP macro generated subroutine. 

Issuance of a Supervisor WAIT or STIMER 
macro instruction from the user-written 
subroutine halts all processing of LPS 
macro instructions. They, therefore, 
should either not be used in the user- 
written subroutine^ or be used with extreme 
care. 



METHODS OF INCLUDING THE SUBROUTINE 



There are three ways cf including a user- 
written subroutine in the LPS: 

1. As a closed subroutine activated by 
the MODE macro instruction,. 

2. As a closed subroutine independent of 
the MODE macro instruction. 

3. As an open, or in-line, subroutine 

In all three cases,, the user can employ 
the SCAN second level subroutine to locate 
the desired portion of the message header. 

In writing open or closed subroutines, 
the user may find useful the information on 
QTAM register assignments contained in 
Appendix D,. 

Figure 19 indicates which registers are 
available and which are not available to 
user-written subroutines.. A register des- 
ignated as available is one that need not 
have its original contents restored by the 
user-written subroutine prior to the return 
to the LPS. Therefore, in the "Subroutine 
Activated by MODE" column, registers 
required for linkage are listed as "not 
available. " In the LPS section,, the con- 
tents of the registers available to the 
user are not preserved by the QTAM macro 
instruct ions . 



ACTIVATION OF A CLOSED SUBROUTINE THROUGH 
MODE : The MODE macro instruction can be 
used to provide the necessary linkages for 
a user-written subroutine^ and to activate 
the subroutine. The method of coding this 
macro instruction is described under the 
NODE macro instruction description. 
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If MODE is used, register 1 must be the 
base register for the closed subroutine; a 
USING statement referencing this register 
should be included in the subroutine. MODE 
uses register 14 to return from the user- 
written subroutine to the next statement in 
the LPS. The last instruction in the user- 
written subroutine must be a branch to 4 
plus the contents of register 14. 

If the user executes a non-QTAM macro 
instruction in the routine activated by 
MODE, it is possible that the contents of 
registers 0, 1, 14, and 15 might be 
destroyed upon return from that macro 
instruction. The user is therefore advised 
to save and to restore these registers as 
needed. 

If messages from two or more communica- 
tion lines are being processed simul- 
taneously by an LPS from which a user rou- 
tine is activated, the user routine need be 
serially reusable only on a segment basis. 

Figure 20 shows control flow between an 
LPS containing the MODE macro instruction 
and the user-written subroutine activated 
by MODE. 

INDEPENDENT ACTIVATION OF A CLOSED SUBROU- 
TINE ; If the user elects to activate a 
closed subroutine without using MODE, he 
must provide his own linkages; the linkage 
restrictions described under Activation of 
a Closed Subroutine through MODE are not 
applicable. Figure 21 shows control flow 
between an LPS and a closed user-written 
subroutine not activated by MODE. 

USING AN OPEN SUBROUTINE : The user can 
include his subroutine as an open, or in- 
line, subroutine. No linkage restrictions 
are imposed. Figure 22 illustrates this 
method of program modification. 



THE SCAN SUBROUTINE 



The user-written subroutine can take advan- 
tage of the SCAN facility to locate a por- 
tion of the message header. SCAN is avail- 
able to the user as a second level subrou- 
tine; that is, the user-written routine can 
transfer control to the SCAN subroutine. 

The following instructions effect the 
transfer: 



r t t t 1 

j Name | Operat ion | Operand | Comments j 
j. + + + ., 

|L | 15, 4 (0, 7) | Get address 

| | | of SCAN 

j j j subroutine 

|BALR 13,15 j Branch and 

| j j link to SCAN 

L i X -L J 



The size of the field to be located by SCAN 
must be contained in a halfword; register 
14 must point to this halfword to enable 
the SCAN subroutine tc obtain the field 
size specification. The size may be from 
one to eight characters. If the user- 
written subroutine is activated through the 
MODE macro instruction, register 14 is set 
to point to a halfword indicating a field 
size of 1. If the user changes the con- 
tents of register 14 (that is, has register 
14 point to a halfword containing a dif- 
ferent size specification), he must restore 
the original contents of register 14 before 
returning from his subroutine. This is 
necessary because under MODE register 14 
also provides the return linkage to the 
LPS. 

Figure 23 shows control flow between an 
LPS containing the MODE macro instruction* 
a closed user-written subroutine activated 
by MODE, and the LPS SCAN subroutine 
branched to by the user-written code. 

If the user-written subroutine is em- 
ploying SCAN and is net entered through the 
MODE instruction, the user must set a field 
size pointer in register 14. In this case, 
the previous contents of register 14 need 
not be preserved. 

The SCAN subroutine operates on either a 
fixed- length or a variable-length field 
format. In the case cf fixed-length 
fields, the size indicated by the halfword 
referred to by register 14 can be from one 
to eight; this value indicates the extent 
of the scan. To determine the starting 
point of the field to be scanned, SCAN 
searches for the first nonblank character. 
From this point, SCAN moves the number of 
characters specified by the field length 
halfword into a work area whose address is 
contained in register 2. Any blanks within 
the field are skipped and not counted in 
the field length. Register 5 points to the 
last character in the field at the termina- 
tion of the fixed-length scan. 
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NO. 




1 

2 
3 

4 

5 
6 

7 
8 

9 
10 
11 
12 
13 
14 
15 



| 

Available to Subroutine 
Activated by MODE 



Function 



Parameter Register 

Parameter Register, 

Mode Subroutine Base Register 

Scan Work Word Address Register 

Return Register (Second level) 

LCB Address Register 

Scan Pointer Register 

Buffer Address Register 

LPS Routine Base Register 

Terminal Table Source Entry 
Register 

Work Register 

Work Register 

End of Segment Address Register 

Scan Increment Register 

Reserved for Save Area Address 

Return Register (First level) 

Subroutine Base Register 



Available to Subroutine 
Not Activated by MODE 



— l 

I 

-1 v 



— 1 



Initialized By 



Mode Subroutine 

Scan Subroutine 

BALR Instruction 

Startup Subroutine, 
Send Scheduler 

Startup Subroutine 

QWAIT Subroutine 

Startup Subroutine 

Startup Subroutine 



Startup Subroutine 
Scan Subroutine 

BALR Instruction 
BALR Instruction 



| Yes 


Yes 


|No 


Yes 


| Yes 


Yes 


| Yes 


Yes 


|No 


No 


|No 


No 


|No 


NO 


|No 


NO 


|NO 


NO 


| Yes 


Yes 


| Yes 


Yes 


|No 


NO 


| Yes 


Yes 


|No 


NO 


|No 


Yes 


| Yes 


Yes 



Figure 19. Register Assignments 
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• 






• 






• 
(Data Set Initialization Macro Instructions) 

• 




LPS1 


• 

LPSTART Identifies the beginning 
# of the line group routine 
• 
• 
(Other LPS Macro Instructions) 
• 






• 
MODE USERRTN — i 
— *■ (Next LPS Macro Instructions) 

• 
• 
• 










►USERRTN BALR 1,0 






USING *,1 
(First Executable Instruction in the User -Written Subroutine) 

• 








• 
4(0,14) Branch back to LPS 








END 



Figure 20. Activation of a User-Written Subroutine through MODE 
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• 








• 








• 
(Data Set Initialization Macro Instructions) 

• 






LPS1 


• 

LPSTART * Identifies the beginning 
# of the line group routine 
• 
• 
(Other LPS Macro Instructions) 
• 








• 
BAL 14, USERRTN-^ 
— ^ (Next LPS Macro Instructions) 

• 
• 
• 












_ 


*■ USERRTN BALR 1 , 
USING *,1 

(Other executable Instructions in the User 

• 


-Written Subroutine) 








• 
14 










END 



Figure 21. Activation of a Closed, User-Written Subroutine Independent of MODE 



(Data Set Initialization Macro Instructions) 



LPS1 



LPSTART 



Identifies the beginning of the line group subroutine 



(Other LPS Macro Instructions) 
USERRTN (First Instruction in the User -Written Subroutine) 
(Last Instruction in the User -Written Subroutine) 
(Other LPS Macro Instructions) 



Figure 22. Inclusion of an Open, User-Written Subroutine in the LPS 
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(Data Set Initialization Macro Instructions) 



LPS1 



LP START 



Identifies the beginning 
• of the line group routine 



(Other LPS Macro Instructions) 



MODE USERRTN — 

(Next LPS Macro Instructions) 



IECKSCAN (First Instruction of 
SCAN Subroutine) 



BR 

END 



■USERRTN BALR 1,0 

USING *, 1 

(First Executable Instruction in User -Written Subroutine) 

• 

• Get address of Scan 

• subroutine Branch 
and link to SCAN 



L 15,4(0,7) 

— BALR 3,15 

(Next Instruction in User -Written Subroutine) 



B 

END 



4(0,14) 



Figure 23. Use of SCAN by a User-Written Subroutine Activated by MODE 



If the field size in the halfword 
referred to by register 14 is FFFF (hexa- 
decimal) , SCAN operates on a variable- 
length field format. SCAN searches for the 
start of the next field; the start of a 
field occurs at the next nonblank charac- 
ter. From this point, SCAN begins moving 
characters into a work area whose address 
is contained in register 2. The movement 
of characters terminates either with the 
character immediately preceding the next 
blank, or with the eighth character in the 
field, whichever comes first. (Intervening 
blanks terminate the scan, causing an error 
that is not recorded.) At the termination 



of the scan, register 5 points to either 
the blank character following the field or 
to the eighth character in the field, 
depending on which came first. 



CONSIDERATIONS FOR REGISTER ASSIGNMENT : 
The SCAN subroutine uses and destroys reg- 
isters 2„ 5 # 9, 10, and 12- The user must 
specify registers 3 and 15 in the Branch 
and Link instruction to the SCAN subrou- 
tine. SCAN uses register 3 for return to 
the user's routine. A USING statement in 
SCAN defines register 15 as the base 
register. 
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NETWORK CONTROL FACILITIES 



EXAMINING AND MODIFIYING THE 



TELECOMMUNICATIONS SYSTEM 



Examination and modification of the status 
of the telecommunications system is prin- 
cipally done in the message processing pro- 
gram. For a complete discussion refer to 
the QTAM Message Processing Program Ser- 
vices publication. 



Macro instructions are provided by QTAM 
to examine and modify the status of the 
system at the time the message control pro- 
gram initiates and activates the system. 
Execution of these macro instructions must 
occur between that of the OPEN and ENDREADY 
macro instructions. 

Macro instructions that may be used to 
examine and modify the status of a system 
enable the user to: 

• Activate a stopped line r( STARTLN macro 
instruction) . 

• Add the four threshold counters for a 
line to the four cumulative counters 
for that line, examine the cumulative 
counters, and reset the threshold 
counters (COPYC macro instruction) . 

• Examine and modify the terminal table 
entries (COPYT and CHNGT macro 
instructions) . 

• Examine queue control blocks for DASD 
destination and process queues (COPYQ 
macro instruction). When these macro 
instructions are used in the LPS, QTAM 
ensures that register 13 contains the 
address of an 18-word save area. 



ACTIVATING A STOPPED LINE 



QTAM provides means of activating a stopped 
line through the STARTLN macro instruction. 



Start Line (STARTLN) Macro Instruction 



group. The user must have previously 
opened the line group in the message 
control program,. 



If a line is deactivated by a STOPLN 
macro instruction issued in the message 
processing program, or if the line was 
opened idle, STARTLN must be issued before 
message transmission on that particular 
line can resume. 



In all the preceding cases, if polling 
is used, the presence of an active polling 
list is a prerequisite for message trans- 
mission. (An active polling list is one in 
which the second byte of the list is a non 
zero character — this character is ini- 
tialized as a 1 and can be changed by the 
CHNGP macro instruction. ) If STARTLN is 
used, polling or enabling of input lines 
begins after the execution of that macro 
instruction. Initial polling or enabling 
of input lines in a line group begins when 
the line group is opened in the message 
control program. If activation of a line 
group was deferred by inclusion of the IDLE 
operand in the OPEN macro for the line 
group, a STARTLN macro must be issued to 
activate the lines. 

An attempt to initiate input/output 
operations on a line with a control unit 
that is not operational will result in the 
following sequence of system error 
messages: 

IEC804I CONTROL UNIT NOT OPERATIONAL 
IEC804A REPLY CONT OR POST 

If CONT is replied, the operation will be 
retried. If the action taken is not suc- 
cessful, the series of messages will be 
issued again. If POST is replied, the line 
will be ignored until a STARTLN macro is 
issued to that line, or a STARTLN control 
message for that line is sent. If the con- 
trol unit is still not operational, the 
entire sequence will be repeated. As with 
any WTOR message, the control program is in 
the wait state until the reply is received. 



STARTLN can be used to: 

1. Allow message transmission to resume 
on a particular line in a communica- 
tion line group. 

2. Allow message transmission to resume 
on all lines in a communication line 



r t t 1 

]Name (Operation] Operand j 

j. + 1 ^ 

| [symbol] | STARTLN | termname, /rln) | 

I I 1 \ALL/ | 

L X X J 

symbol 

the name of the macro instruction. 
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termname 

the name of any terminal in the line 
group, but not necessarily the name of 
a terminal on the line being started. 
If register notation is used, the 
register must contain the address of 
the data control block for the line 
group,. It cannot contain the terminal 
name. If an invalid terminal name is 
specified, an error code of hex '20', 
right-adjusted, is set in register 15. 
If the DCB for the line group has not 
been opened, an error code of hex * 01* 
is set in register 15. In either 
case, the STARTLN has no effect. 



rln 



ALL 



line group, of the line to be reacti- 
vated. If register notation is used, 
the general register specified must 
contain the relative line number in 
binary form. If an invalid relative 
line number is specified, a hexadeci- 
mal code of '08 1 , right-adjusted, is 
set in register 15. 



specifies that all lines in the line 
group are to be activated. 



If no errors were detected in the STARTLN 
macro, register 15 contains all zeros. 



EXAMINING AND MODIFYING THE TERMINAL TABLE 



QTAM provides macro instructions that 
enable the user to examine and to change 
dynamically the control information con- 
tained in a terminal table entry. 

The COPYT macro instruction causes the 
contents of a specified terminal table 
entry to be copied into a work area. This 
macro instruction can be used in conjunc- 
tion with the CHNGT macro instruction, 
which substitutes a new terminal table 
entry for a superseded one. The user 
issues a COPYT, examines the information, 
changes it if necessary, and issues a 
CHNGT. 

The user can also change terminal table 
information via a RELEASEM macro instruc- 
tion issued in the message processing 
program. 



Copy Terminal Table Entry (COPYT) Macro 
Instruction 



COPYT moves the information contained in a 
specified terminal table entry into a des- 
ignated work area. The terminal table 
entry can be either a single terminal, 
group code, distribution list, or process 



program entry. Formats for each of these 
entries are shown in Appendix A. 

r t t 1 

1 Name | Operation j Operand | 

j. + + 1 

I ] [symbol] | COPYT ] termname, workarea | 

• i -L j. J 

symbol 

the name of the macro instruction. 



termname 

the name of the terminal whose termi- 
nal table entry is to be copied. If 
register notation is used, the general 
register designated must contain the 
address of a location containing the 
name of the terminal. The terminal 
whose address is in the register must 
be padded with blanks to the length of 
the maximum size TERM entry in the 
terminal table. If an invalid termi- 
nal name is specified, no data move- 
ment takes place; the routine linked 
by the COPYT macro instruction returns 
an error code of hex '20' right- 
adjusted, in register 15. If no error 
is detected, register 15 contains 
zero. 

workarea 

the address of the area into which the 
information is placed. The first byte 
of the work area receives the first 
byte of data from the terminal table 
entry. The maximum size of the work 
area is 2 52 bytes (the maximum size of 
a terminal table entry). If register 
notation is used, the general register 
designated must contain the address of 
the work area. 



Change Terminal Table Entry (CHNGT) Macro 
instruction 



CHNGT moves the information for a terminal 
table entry from a designated work area to 
the terminal table area allocated for that 
entry. In order to change the entire con- 
tents, including TSEQUIN and TSEQOUT, the 
user must precede the CHNGT macro with a 
STOPLN macro for the line on which the 
affected terminal is located. A STOPLN 
macro should be issued before a COPYT-CHNGT 
sequence so that the fields of the terminal 
table are not changed between the time the 
entry is copied and the time it is changed. 

CHNGT is normally preceded by the COPYT 
macro instruction and instructions to 
examine and modify the contents of the 
copied terminal table entry. The user must 
be certain that the new terminal table 
entry contains all the information required 
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for proper execution of QTAM. The format 
of the terminal table entries and the 
information contained in each field are 
contained in Appendix A. 



examines the information, changes it if 
necessary, and issues a CHNGP. CHNGP can 
also be used to stop or restart polling of 
the terminals on a line. 



T T T 1 

| Name | Operat ion | Operand | 

j. + x ^ 

| [ symbol ] | CHNGT | termname, workarea | 

L X X J 



Copy Polling List (COPYP) Macro Instruction 



symbol 

the name of the macro instruction. 

termname 

the name of the terminal whose termi- 
nal table entry is to be replaced. It 
must be the same as a name that 
appears in the name field of a TERM, 
PROCESS, or DLIST macro instruction. 
If register notation is used,, the 
address of a location containing the 
name must be in the general register 
designated. The terminal name whose 
address is in register irust be padded 
with blanks to the length of the maxi- 
mum size TERM entry in the terminal 
table. 

If an invalid name is specified, the 
routine generated by CHNGT returns an 
error code of hex '20', right- 
adjusted, in register 15,. QTAM subse- 
quently disregards the new terminal 
taole entry and continues to use the 
old. 

workarea 

the address of the area from which the 
information is moved. If register 
notation is used, the general register 
specified must contain the address of 
the work area. If the new entry does 
not equal the size of the old entry, 
no data movement takes place. An 
error code of hex '10' is returned in 
register 15, and QTAM continues to use 
the old entry. 

If no errors were detected in the CHNGT 
macro, register 15 contains all zeros. 



EXAMINING AND MODIFYING POLLING LISTS 



QTAM provides macro instructions that 
enable the user to examine and modify the 
contents of the polling list for a line. 

The COPYP macro instruction causes the 
contents of a specified polling list to be 
copied into a work area. This macro 
instruction can be used in conjunction with 
the CHNGP macro instruction, which can sub- 
stitute a new polling list for a superseded 
one (the new list must be the same size as 
the old one) . The user issues a COPYP, 



COPYP causes the polling list for a speci- 
fied line to be copied into a user- 
designated work area. The format of the 
polling list is shown in Appendix A,. 

I T — " T ' 1 

] Name | Oper- 1 Operand | 

| J at ion J | 

y + + < 

| [symbol] | COPYP | termname, rln, workarea | 

l x x J 

symbol 

the name of the macro instruction,. 

termname 

the name of any terminal in the line 
group, but not necessarily the name of 
a terminal in the polling list being 
I copied. If register notation is used,, 
' the register must contain the address 
of the data control block for the line 
group. It cannot contain the terminal 
name. 

If an invalid terminal name is speci- 
fied* an error code of hex '20V, 
right- adjusted, is set in register 15. 
If the DCB for the line group has not 
been opened, an error code of hex *01' 
is set in register 15. In either 
case, the COPYP has no effect. 

rln 

the relative line number-, within the 
line group,, of the line whose polling 
list is to be copied,. If register 
notation is used, the user previously 
must have placed the relative line 
number (in binary form) in the general 
register designated. If the rln spec- 
ified is invalid, a hexadecimal code 
of "08*, right-ad justed,, will be set 
in register 15. 

workarea 

the address of the work area into 
which the polling list is to be 
copied,. The first byte of the work 
area receives the first byte of data 
in the polling list. The size of the 
area necessary can be determined from 
the polling list format shown in 
Appendix A. If register notation is 
used, the general register specified 
must contain the address of the work 
area. 
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If no errors were detected in the COPYP 
macro, register 15 contains all zeros. 



Change Polling List (CHNGP) Macro 
Instruction 



=C0' 



causes the second byte of the polling 
list be changed to a zero. This 
results in the deactivation of the 
polling list. Nc further messages are 
received until the list is 
reactivated. 



CHNGP can either: 



1. 



Place a new polling list in the poll- 
ing list area for a specified line. 
2. Change the status of a polling list 
for a specified line. 



r t t 

| Name | Oper- | Operand 

J J at ion | 

j. + + 

| [symbol] | CHNGP | termname, rln, 

| j | (workarea} 

I I K=C'0« K 

I I |(=C'l" J 



■H 



—J 



symbol 

the name of the macro instruction. 

termname 

the name of any terminal in the line 
group, but not necessarily the name of 
a terminal in the polling list that is 

I being changed. If register notation 
is used, the register must contain the 
address of the data control block for 
the line group. It cannot contain the 
terminal name. 

If an invalid terminal name is speci- 
fied, an error code of hex '20*, 
right-adjusted, is set in register 15. 
If the DCB for the line group has not 
been opened, an error code of hex '01* 
is set in register 15. In either 
case, the CHNGP has no effect. 

rln 

the relative line number,, within the 
line group, of the line whose polling 
list is to be modified. If register 
notation is used, the user previously 
must have placed the relative line 
number (in binary form) in the general 
register specified. If the relative 
line number is invalid (the line group 
has no such line number) an error code 
of hex '08', right-adjusted, is set in 
register 15. 

work area 

the address of the area that contains 
the new polling list. The first byte 
of the polling list area receives the 
first byte of data in the work area, 
takes place. An error code of hex 
*10* is set in register 15. QTAM sub- 
sequently disregards the new polling 
list and continues to use the old. 



causes the second byte of the polling 
list to be changed to a one. This 
results in the activation of the poll- 
ing list. QTAM begins polling the 
terminals on the line and accepting 
incoming messages. 

If no errors were detected in the CHNGP 
macro, register 15 contains all zeros. 



EXAMINING QUEUE CONTROL BLOCKS 



Each terminal table entry defined by a TERM 
or PROCESS macro instruction contains the 
address of the queue control block (QCB) 
for the DASD destination or DASD process 
queue on which outgoing messages to the 
destinations are placed. QTAM uses the QCB 
for: 

1. Placing each message on its appropri- 
ate DASD queue. 

2. Maintaining information on the status 
of the queue. 

The COPYQ macro instruction enables the 
user to examine a QCB to ascertain the sta- 
tus of the DASD destination or DASD process 
queue associated with the QCB. 

Figure 24 shows the contents and rela- 
tive displacement of each field in the QCB 
that is of interest to the user. After 
issuing a COPYQ macro instruction to copy 
the QCB into a user-specified work area, 
the user can deter irine the contents of the 
fields from which he needs information. 
For example,, the user can determine the 
number of messages in the queue, or can use 
the address of the queue on the disk to 
retrieve a message (see the RETRIEVE macro 
instruction description). 



Copy Queue Control Blcck (COPYQ) Macro 
Instruction 



COPYQ places the contents of a QCB into a 
specified work area. The user indicates 
the QCB desired by specifying the name of a 
terminal or the naire cf a DASD process 
queue. If the name of a terminal is speci- 
fied, COPYQ places into the work area the 
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I Legend; 



IQFAC 



I QRLN 



QDCB 



| QSIZE 



the relative record address of the next message to be read from this DASD queue; 
that is,, the next message to be processed or transmitted. 

the relative line number of the line associated with this queue. (Field used onlyj 
for a DASD destination queue.) 

the address of the data control block associated with this QCB. (Field used only 
for a DASD destination queue.) 

! 
the number of complete messages on this queue. 



QNASEG 

the relative record address on the DASD message queue data set where the header 
segment of the next message for this queue will be placed. 

I QBACK 



the relative record address of the last message placed on this DASD queue. 
Figure 24. Format of Queue Control Block (QCB) 



L . J 



QCB for the DASD destination queue asso- 
ciated with that terminal . If the name of 
a DASD process queue is specified, the QCB 
for the DASD process queue is placed into 
the work area. In both cases,, the entire 
contents of the 32-byte QCB are provided. 
However, certain fields are used internally 
by QTAM routines and are not of interest to 
the user (see Figure 24). 

r t t t 

| Name | Operation | Operand | 

L + - + i 

I | [symbol] |COPYQ | termname,, workarea | 
' l x x J 

symbol 

the name of the macro instruction. 

termname 

the name of the terminal or DASD pro- 
cess queue whose associated QCB is to 
be copied. Only the name of a single 
terminal or process program terminal 
table entry can be specified, that is, 



the name specified in a TERM or PRO- 
CESS macro instruction. If specified, 
no data movement takes place. If 
register notation is used, the address 
of a location containing the name must 
be in the designated general register. 
The terminal name whose address is in 
the register must be padded with 
blanks to the length of the maximum 
size TERM entry in the terminal table. 
If an invalid termname is specified, a 
hexadecimal code of '20', right- 
adjusted, is set in register 15. 

workarea 

the address of the area into which the 
contents of the QCB are placed. The 
area must be 32 bytes long (the size 
of the QCB) . If register notation is 
used w the general register specified 
must contain the address of the work 
area. 

If no errors were detected in the COPYQ 
macro, register 15 contains all zeros. 
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This section describes the following ser- 
vices that QTAM provides to aid the user in 
network control, error recovery, operator 
awareness, system failure and system 
closedown: 

• Operator Control Facility 

• Error Recovery Procedures 

• Operator Awareness Messages 

• Checkpoint/Restart Facility 

• Deactivating the Telecommunications 
System 



OPERATOR CONTROL FACILITY 



This section outlines the control messages 
that may be entered from the primary or 
alternate control terminal,, and the func- 
tions they serve. For these messages to be 
considered control messages, the OPCTL 
macro must appear in the Receive Header 
portion of the LPS for messages from this 
type terminal,, and the identifier charac- 
ters must be the first in the header.. 

With Operator Control, the user has the 
capability of selecting one terminal in the 
system as the telecommunications control 
terminal, and another as the alternate con- 
trol terminal. Each of these control ter- 
minals must be nonswitched and may be eith- 
er a 1050 or 2740 with station control. 
Messages received from either of these ter- 
minals, with the designated identifier 
characters,, will be considered control 
messages . 



Control messages may be sent, 
to dynamically: 



in order 



• Copy the cumulative error counters 
(COPYC) . 

• Copy a particular terminal table entry 
(COPYT) * 

• Insert the given data into a given ter- 
minal table entry (CHNGT)- 

• Intercept messages to a given terminal 
(INTERCPT). 

• Release intercepted messages for a 
given terminal (RELEASEM) . 
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• Stop message transmission on a line for 
two minutes, then resume transmission 
on that line (INTREL). 

• Start a line (STARTLN). 



Stop 



line (STOPLN) 



• Switch the primary and alternate con- 
trol terminals (SWITCH). 

The operator control capability provides 
dynamic investigation and modification of 
the control information used by QTAM. Many 
of these same capabilities are available 
with the system modification macros. With 
operator control, only the terminals desig- 
nated as primary or alternate control ter- 
minals are afforded the use of all the fol- 
lowing functions. (For further discussion 
of system modification macros, see the sec- 
tion on Examining and Modifying the Tele- 
communications System.) 

It should be noted that blank characters 
must follow all fields in the header of all 
operator control messages. 



Copy Error Counters 



COPYC causes the four threshold counters of 
the line specified to be added to the four 
cumulative counters for that line and the 
result to be printed on the primary or 
alternate telecommunications system termi- 
nal originating the request. Threshold 
counters are reset. The information is 
printed in hexadecimal format. 



Jmsgname COPYC terirname 

i 



msgname 

is the sequence cf characters speci- 
fied in the CTLMSG parameter of the 
OPCTL macro instruction. 

termname 

is the name of a terminal on the line 
desired. This may not be the name of 
a DLIST or PROCESS entry in the termi- 
nal table. If a DLIST or PROCESS 
entry is specified, the message will 
be returned to the originating termi- 
nal, indicating an error. 

Note : The message will be returned to the 
originating terminal if the line is not 
open. 
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Copy Terminal Table Entry 



COPYT causes the terminal table entry spec- 
ified (starting at the TSEQUIN field) to be 
printed on the telecommunications system 
control (or alternate) terminal originating 
the request. The information is printed in 
hexadecimal format. Only the data that 
will fit into one buffer will be 
transmitted - 

An LPS that inserts time, date, and 
sequence information into the message head- 
er leaves little room in the buffer for 
text information. A terminal table entry., 
after conversion to printable hexadecimal 
format, may require more rooir than is left 
in the buffer. For this reason the user 
should be aware that a separate LPS, which 
does no header manipulation, may be used 
for the operator control terminals . 



|msgname COPYT termname 

L • 



— 1 

I 



msgname 

is the sequence of control characters 
specified in the CTLMSG parameter of 
the OPCTL macro instruction,. 

termname 

is the name of the terminal whose 
entry is to be copied. 



Change Terminal Table Entry 



CHNGT causes the data in the text portion 
of the message to replace the entry in the 
terminal table for the terminal specified. 
The data must be entered in hexadecimal 
format . 

r • 1 

| msgname CHNGT termname data | 

L J 

msgname 

is the series of control characters 
specified in the CTLMSG parameter of 
the OPCTL macro instruction. 

termname 

is the name of the terminal whose 
entry is to be changed. 



data 



is the information in hexadecimal for- 
mat to replace the terminal table 
entry. The data will be placed in the 
terminal table entry beginning with 
the TSEQUIN field. Valid characters 
for this data are 0-9 and A - F. If 
an invalid character is specified in 
this field or if there is an odd num- 
ber of data characters, the message, 



up to and including the termname, will 
be returned to the originating termi- 
nal,, indicating an error in the data 
sent. 



Intercept Messages 



INTERCPT causes the suppression of all mes- 
sage transmission to the terminal specified 
by termname. The untransmitted messages 
remain on the DASD destination queue for 
that terminal. 



| msgname INTERCPT termname 



msgname 

is the series of control characters 
specified in the CTLMSG parameter of 
the OPCTL macro instruction. 

termname 

is the name of the terminal whose mes- 
sages are to be intercepted. This may 
not be the name of DLIST or PROCESS 
entry in the terminal table. If a 
DLIST or PROCESS entry is specified, 
the message will be returned to the 
originating terminal, indicating an 
error. 

If the INTERCPT control message is to be 
used ff the user must specify a 3-byte area 
of the terminal table (see OPTION macro 
instruction description) . For each termi- 
nal for which message transmission is 
suppressed: 

1. The relative record number of the 
header of the first suppressed message 
is placed in the INTERCPT optional 
field of the entry representing that 
terminal. 

2. The intercept bit in the TSTATUS byte 
of the entry is set to 1. 

3. The send bit in the TSTATUS byte for 
that entry is set to 0. 

No further messages are sent to the 
effected terminal until the user resets the 
intercept and send bits. This may be done 
by sending a RELEASEM or CHNGT control mes- 
sage. If RELEASEM is used, all suppressed 
messages (those on the destination queue) 
are sent, as are any new messages. If 
CHNGT is used, only the new messages (those 
placed on the destination queue after CHNGT 
has been issued) are sent. In the latter 
case., the suppressed messages remain on the 
destination queue, and cannot be sent 
unless the user obtains them by a RETRIEVE 
macro instruction and reissues a PUT for 
each of them. 
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If the user ever wishes to issue an 
INTERCPT operator control message, he must 
specify the INTERCPT macro instruction in 
the ENDSEND portion of the LPS. The mask 
in this macro must specify "terminal 
inoperative" (i.e., the mask must be at 
least a hexadecimal HO 00) . If the INTRCPT 
parameter is not specified in the OPCTL 
macro, this message will be returned to the 
originating terminal, indicating an error. 



Interval Stop 



INTREL causes the interruption of all mes- 
sage transmission on the line containing 
the terminal specified,. The function is 
the same as for STOPLN except that all 
transmission on the designated line is 
halted for two minutes following the recep- 
tion of this message. After the two 
minutes of no transmission the line is 
started again and message transmission 
resumes until an irrecoverable error 
occurs. When an irrecoverable error does 
occur, message transmission is stopped for 
another two minute interval. If no irre- 
coverable error occurs, message transmis- 
sion continues normally. INTREL will con- 
tinue until a STARTLN control message is 
received or until a STARTLN macro is 
encountered. 



msgname INTREL termname 



— n 

I 
j 



msgname 

is the series of control characters 
specified in the CTLMSG parameter of 
the OPCTL macro instruction. 

termname 

is the name of any terminal on the 
line to be effected by this interrup- 
tion of message transmission. This 
may not be the name of a DLIST or 
PROCESS entry in the terminal table. 
If a DLIST or PROCESS entry is speci- 
fied,, the message will be returned to 
the originating terminal, indicating 
an error. 



Release Messages 



RELEASEM causes intercepted iressages for a 
terminal to be released. This is achieved 
by setting to zero the intercept bit in the 
TSTATUS byte in the terminal table entry 
for the specified terminal. 

It should be noted that messages for 
this terminal that were intercepted and 
later released will not be transmitted 
immediately. The queue of messages for 



this terminal must be "primed" by having 
another message put on that queue. The 
presence of this message on the queue 
causes QTAM to attempt to contact the ter- 
minal. If the terminal is free, the mes- 
sages on the queue are transmitted by 
priority. if the terminal is busy, the 
messages will not be transmitted at that 
time. 

If RELEASEM operator control messages 
are to be accepted from the telecommunica- 
tions control terminals, the INTRCPT=YES 
operand must be coded in the OPCTL macro 
instruction and a 3-byte OPTION field 
labeled INTERCPT must be defined for the 
terminal table entries. 



| msgname RELEASEM termname 

L 



msgname 

is the series of control characters 
specified in the CTLMSG parameter of 
the OPCTL macro. 

termname 

is the name of the terminal whose mes- 
sages are to be released. Messages 
for this terminal must have been pre- 
viously intercepted by having an 
INTERCPT macro for this terminal in 
the LPS, or by issuing an INTERCPT 
operator control message for this 
terminal. 

Note ; If INTRCPT=YES is not specified in 
the OPTCL macro instruction and a RELEASEM 
operator control message is received, the 
message will be returned to the originating 
terminal, indicating an error. 



Stop Line 



The STOPLN control message removes a com- 
munication line, or lines, from active use. 
Operations on the designated line or lines 
are stopped. 



j msgname STOPLN termname [ALL] 

i 



msgname 

is the series of control characters 
specified in the CTLMSG parameter of 
the OPCTL macro. 

termname 

is the name of a terminal on the line 
to be stopped. If all the lines in 
the line group are to be stopped, this 
may be the name of any terminal in 
that line group. This field may not 
be the name of a DLIST or PROCESS 
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ALL 



entry in the terminal table, or the 
name of the source terminal. If any 
of these is specified, the message 
will be returned to the originating 
terminal, indicating an error. 

It must be remembered that the control 
terminal or alternate terminal cannot 
be stopped by a message from itself. 
There would be no way of restarting 
the terminal. 



specifies that all the lines in a line 
group are to be stopped. The line 
group is determined by the termname. 
If this operand is omitted, only the 
line containing the teririnal mentioned 
in termname will be stopped. 

If the DCB for the line involved has not 
been opened, the message will be returned 
to the originating terminal, indicating an 
error. 



PROCESS entry is specified, the mes- 
sage will be returned to the originat- 
ing terminal, indicating an error. 



ALL 



when used* this signifies that all the 
lines in the line group are to be 
started. If omitted, only the line 
with the terminal specified by term- 
name will be started. 

In all of the above cases, if polling is 
used, the presence of an active polling 
list is a prerequisite for message trans- 
mission. (An active polling list is one in 
which the second byte of the list is a non- 
zero character — this character is ini- 
tialized as a one and can be changed by the 
CHNGP macro instruction.) If STARTLN is 
used, polling of input lines begins after 
the execution of that control message. 



Switch Primary Terminal 



Start Line 



STARTLN can be used to: 

1. Allow message transmission to resume 
on a particular line in a communica- 
tion line group. 

2. Allow message transmission to resume 
on all lines in a communication line 
group. 



SWITCH causes the alternate telecommunica- 
tions control terminal to receive error 
messages. If the alternate terminal is 
presently set to receive error messages, 
this message causes the primary terminal to 
receive messages. 

If no alternate terminal has been speci- 
fied in the OPCTL iracro instruction, the 
message will be returned to the originating 
terminal, indicating an error. 



The user must have previously opened the 
line group in the message control program. 
If the DCB is not open, the iressage will be 
returned to the originating terminal, indi- 
cating an error. 

If a line is deactivated by a STOPLN 
control message, STARTLN must be issued 
before message transmission on that partic- 
ular line can resume. This control message 
will also reset the Interval Step (INTREL) 
condition. 



|msgname STARTLN termname [ALL] 

L 



— 1 

I 
J 



msgname 

is the series of characters specified 
in the CTLMSG parameter of the OPCTL 
macro. 

termname 

is the name of the terminal on the 
line to be started. If all lines in a 
line group are to be started, then 
this may be any terminal in that line 
group. This may not be the name of a 
DLIST or PROCESS entry. If a LIST or 



] msgname SWITCH 

L 



msgname 

is the series of characters specified 
in the CTLMSG parameter of the OPCTL 
macro instruction. 



Invalid Operator Control Messages 



It must be noted that the console commands 
are completely analogous to the message 
processing macros of the same name, and can 
therefore be nullified by later occurrence 
of the macros. For instance,, if the opera- 
tor issues a STOPLN and the message pro- 
cessing program encounters a STARTLN, the 
line will be started. 

In addition to the situations mentioned 
in the discussions of the individual con- 
trol messages,, the control message will be 
returned to the originating terminal 
whenever: 
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1. The input message is longer than one 
buffer, including EOB and EOT 
characters. 

2. The operation cannot be identified. 

3. The terminal name is invalid. 

If an operator has his message returned 
immediately,, he should first check the 
termname for validity, and then check the 
operation name he has specified. After 
this , he may check the length of the mes- 
sage against the length of the buffer. 
Next, he should check the discussion of the 
control message he has just sent for indi- 
vidual circumstances that might cause the 
message to be returned. 

Example ; Assume that the user wishes to 
stop all lines in a particular line group,. 
TERM1 is the name of a terminal on a line 
in the line group to be stopped. CTL are 
the control characters for an operator con- 
trol message. The lines in the line group 
can be stopped by issuing 

NCTL STOPLN TERM1 ALL EE 
L 00 

BT 



is the New Line character 



and CSW status bits tc determine which type 
of error has occurred. Depending upon the 
type of error, the following functions may 
be performed: 

1. the failing action is retried two 
times, and on the third occurrence of 
the error an operator message is 
provided; 

2. an operator message is immediately 
provided; 

3. the type of failing action is recorded 
in a threshold counter, statistical 
data recorder, or outboard recorder, 
depending upon the type of error; 

4. a combination of 1, 2, and 3, depend- 
ing upon the type of error detected. 



Note ; If the error is counted in a thresh- 
old counter, it is counted every time that 
it occurs, including both of the retry 
attempts. Messages tc the operator are 
normally sent to the 1052 system console.. 
However, if the OPCTL operand is specified 
in the TERMTBL macro instruction, the mes- 
sages are sent to the telecommunications 
control terminal. For further information,, 
refer to the section on the TERMTBL macro 
instruction and the section on Operator 
Control . 



is the End-of-Block character 



is the End-of-Transmission character 



Blank characters must follow all fields 
in the header, including the last. 

If the terminal that issued the message 
is on the line or in the line group to be 
stopped, the message will be returned to 
that terminal, indicating an error. This 
is to protect the user from permanently 
stopping the line that his control terminal 
is on. 



ERROR RECOVERY PROCEDURES 



The error recovery procedures are a compre- 
hensive set of routines for dealing with 
all kinds of input/output errors that may 
occur within the telecommunications system. 

When an I/O error occurs, the error 
recovery procedures examine the sense bits 



Eight counters are provided for each 
line in the system: four threshold count- 
ers and four cumulative counters. Each 
cumulative counter corresponds to one of 
the threshold counters. 

The threshold counters keep a count of 
the number of (1) transmissions, (2) data 
checks, (3) intervention required errors, 
and (4) nontext tiire-cuts. 

whenever one of the three error thresh- 
old counters (but not the transmission 
threshold counter) reaches a specified 
threshold value, the following action is 
performed: 

• each threshold counter is added to the 
corresponding cumulative counter; 

• a message is provided to the operator 
showing the value in each threshold 
counter at this time; and 

• the threshold counters are reset to 
zero. 



Whenever the transmissions threshold 
counter reaches its threshold value, the 
cumulative counters are incremented and the 
threshold counters are reset to zero, but 
no message is provided. 
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The threshold values represent the num- 
ber of three types of errors considered 
excessive within a certain number of total 
transmissions. These values are specified 
in the THRESH operand of the DCB macro 
instruction for the line group in which the 
line is located. The threshold value for 
any of the four threshold counters must not 
be more than 255. However, the threshold 
values specified for any of the three error 
counters should be enough less than that 
specified for the number of transmissions 
to allow an error message to be provided. 
If the THRESH operand is omitted from the 
DCB for the line group, the following 
values are assumed: 

Number of transmissions - 255 

Number of data checks =10 

Number of intervention required errors 
= 5 

Number 'of nontext time-outs = 5 



ee 



ff 



is the sense information resulting 
from the issuance of a diagnostic 
write/read, write/break,, or read/skip 
sequence if it resulted in a unit 
check (in hexadecimal format). 



is the TP Op code as specified in the 
failing CCW in the channel program (in 
hexadecimal format) . 



99 



hhhh 



always zero. 



is the terminal ID (polling or ad- 
dressing characters) in hexadecimal 
format,. If only one polling character 
is used it will be left-justified in 
this field. If this is a dial line,, 
this field is the last four digits. 



OPERATOR AWARENESS MESSAGES 



This section describes those messages sent 
by QTAM to notify the user of error condi- 
tions that could affect normal operations. 
These messages will be written on the sys- 
tem console unless the operator control 
facility is included and the OPCTL operand 
is coded in the TERMTBL macro instruction. 
In this case,, these messages (except for 
the message identification number) will be 
sent to the telecommunications control 
terminal . 

The following message results when a 
permanent or irrecoverable I/O error has 
occurred on the line: 



The following message results when the 
system detects excessive temporary errors 
as determined by the line error threshold 
counters : 



IEC801I THRESHOLD aaa TRANS=bbb DC=ccc 
IR=ddd TO=eee 



THRESHOLD 

identifies this as an error threshold 
message,. 



aaa 



is the line address in hexadecimal 
format. 



IEA000I I/O ERR,,aaa,bb w cccc,ddee w f fgghhhh 

aaa 

is the line address in hexadecimal 
format. 



TRANS=bbb 

bbb is the nuirber of transmissions 
attempted up to the time an error 
threshold was reached. This informa- 
tion is in decimal format. 



bb 



cccc 



is the command code as specified in 
the failing channel program in hexa- 
decimal format. 



is the status bytes of the channel 
status wbrd (CSW) as specified in the 
input/output block (IOB) in hexadeci- 
mal format. 



DC=ccc 

ccc is the nuirber of data checks that 
occurred, in decimal format, in the 
past bbb transmissions. 

IR=ddd 

ddd is the number of intervention 
required errors that occurred, in 
decimal format, in the past bbb 
transmiss ions . 



dd 



is the first sense byte as specified 
in the input/output block (IOB) in 
hexadecimal format. 



TO=eee 

eee is the number of nontext time-out 
errors that occurred, in decimal for- 
mat, in the past bbb transmissions. 
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CHECKPOINTING AND RESTARTING THE MESSAGE 



CONTROL PROGRAM 



QTAM provides the facility for writing 
checkpoint records on a data set under con- 
ditions specified by the user. Checkpoint 
records contain the information necessary 
to record the status of the queues and of 
the telecommunications network. Restart 
provides the facility of restoring the 
queues and the network to its status just 
prior to the last checkpoint record taken. 
These facilities enable the user to rees- 
tablish the system if a system failure 
should occur, without loss of messages 
already entered in the system. 



CHECKPOINTING THE MESSAGE CONTROL PROGRAM 



The user may specify that checkpoint rec- 
ords are to be taken either at specified 
intervals of time or at desired points in 
one or more message processing programs. 

Checkpoint causes records to be written 
as specified on a checkpoint data set main- 
tained on a direct access storage device. 
Specifically, the checkpoint records 
include the polling lists, the terminal 
table, disk pointers, and status informa- 
tion associated with each queue, and disk 
pointers and status information associated 
with each line. Note that the data in the 
buffers is not included in the checkpoint 
record. The format of the checkpoint rec- 
ords is shown in Appendix I. Two such 
checkpoint records are maintained in the 
checkpoint data set along with a pointer to 
the most recent record. At user specified 
intervals a new checkpoint record is writ- 
ten over the oldest existing record and the 
pointer is updated to reflect the most 
recent record. Should a system failure 
occur during checkpoint itself,, restart may 
still be accomplished using the alternate 
checkpoint record. 

Checkpointing is initiated by: 

1. Allocating space on the DASD for the 
checkpoint data set. 

2. Defining the checkpoint data set. 

3. Opening and closing the checkpoint 
data set. 

H.. Either using the CPINTV keyword 

operand in the TERMTBL iracro instruc- 
tion (if checkpoint records are to be 
taken at specified intervals of time) 
or using the CKPART operand in the 
TERMTBL macro instruction (if the rec- 
ords are to be taken at certain points 



in the processing programs). If the 
CKPART operand is used, the CKREQ 
macro instruction must be issued in 
each processing program to be used in 
determining when to take the check- 
point records (see the publication IBM 
the publicatio nlBM System/360 Operat- 
ing System: QTAM Message Processing 
Program Services . 

Note : If checkpointing is specified at 



time intervals (CPINTV operand in the 
TERMTBL macro instruction),, no additional 
instructions are necessary in the process- 
ing programs (i-e. checkpointing is inde- 
pendent of the processing programs) . 

Restart allows the user to re-establish 
the queues and the telecommunications net- 
work to its status just prior to the last 
checkpoint. 



Allocating Space on the DASD 



The checkpoint data set should be main- 
tained on a permanently resident DASD. 
Space must be allocated on the DASD the 
first time the data set is used. The num- 
ber of tracks required may be calculated 
from the formula: 

T=[288 + 2(S,.+ 11N DG + 14N PQ +11N 1 +S P1 + Sp 2 + 
+ Sp n )]/ 3625 



Where : 

T 



St 



= Number of tracks; must be 
rounded to the next high- 
er integer. 

= Size in bytes of the ter- 
minal table. 

= Number of destination 
queues. 

= Number of process queues. 

= Number of lines. 



Spi+Sp a + - •-+Sp n = Sum of the sizes of the 
polling lists,. 

For example: 

Consider a telecomnunications system con- 
sisting of nonswitched IBM 1050s in the 
following configuration: 

3 lines with 3 terminals each w queued by 
line 

2 lines with 2 terminals each„ queued by 
terminal 

1 processing entry in the terminal table 

All terminal names are 5 characters. No 
optional fields are used in the terminal 
table. 
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From Appendix A, the terminal table size is 
&r = 248. There is one destination queue 
for each line queued by line, one destina- 
tion queue for each terminal queued by ter- 
minal and one process queue. Thus N DQ =7 
andN PQ =l. For the 5 lines,, N L =5. 



From the polling list formats in Appendix 
A, three lines have polling lists of 12 
bytes each and two lines have polling lists 
of 10 bytes each. Thus S p i+Sp 2 +. . .Sp 5 =56 

Therefore T = [288 + 2(248 + 11(7) + 14(1) 
+ 11(5) +56)]/ 3625 = .33 

A value of T = 1 must then be used in SPACE 
allocation. 

A DD card is used to allocate space for the 
checkpoint data set. The name of the DD 
statement must be TPCHKPNT,. Secondary 
space allocation is not used in the TRK 
parameter. 

A typical DD card used for initial alloca- 
tion is: 

//TPCHKPNT DD DSNAME=CPDS, UNIT=SYSDA, 
// VOLUME=SER= 111111, 

// SPACE= (TRK, (1) ) , 

// DISP= (NEW, KEEP) 

A typical DD card used for the same check- 
point data set after initial allocation is: 



//TPCHKPNT DD 



DSNAME=CPDS ,UNIT=SYSDA, ( 
DISP=OLD 



Defining the Checkpoint Data Set 



The checkpoint data set must be specified 
by a DCB macro instruction. The format of 
this instruction is found in a previous 
section entitled Data Set Definition. The 
DCB macro instruction will be written as 
follows: 

DCB DSORG=CQ , MACRF= (G„ P ) , 
DDNAME=TCHKPNT 



Opening and Closing the Checkpoint Data Set 



The checkpoint data set must be opened 
after the DASD message queues data set and 
before the communication line group data 
sets. The checkpoint data set must be 
closed after the communication line group 
data sets and before the DASD message 
queues data set. 



RESTARTING THE MESSAGE CONTROL PROGRAM 



When operating with the checkpoint/ restart 
option, the user may restart the message 
control program at any time- Restart rees- 
tablishes the queues and the telecommunica- 
tions network to the status it had just 
prior to the most recent checkpoint. 
Restart is accomplished by reloading the 
program after changing the DISP parameter 
in the DD card for the checkpoint data set 
to a DISP=OLD. The checkpoint data set is 
then examined. If this data set had been 
properly closed, normal operation takes 
place; no special action is necessary for 
normal startup. If this data set had not 
been properly closed, a restart operation 
is performed. If space is being allocated 
for a new checkpoint data set (i.e., 
DISP= (NEW, KEEP) on the DD card) a new star- 
tup is assumed and no restart is possible. 

Restart of the message control program 
will normally require no more than five 
minutes longer than a regular start,. 
Incoming activity on nonswitched lines that 
does not contain normal EOB (or ETX) or EOT 
characters may delay restart. 

If an abend occurs and the user does not 
wish to restart, but merely to startup,, he 
must scratch the checkpoint data set. 

After the restart procedure has been ac- 
complished, the terminals should be noti- 
fied of the delay and instructed to re- 
transmit messages that might have been sent 
during this interval. This leads to the 
possibility that a message may be dupli- 
cated on the message queue. 

At restart time, QTAM has available for 
each terminal the input sequence number of 
the last message successfully received, 
processed by the LPS, and placed on the 
message queue. Messages received after the 
restart will have their input sequence num- 
ber checked against the last valid input 
sequence number from the last checkpoint 
record. If the sequence number is valid, 
processing proceeds as normal. If the 
sequence number is invalid, the message 
control program should take action to noti- 
fy the operator of the terminal that that 
message has already been received and pro- 
cessed by the LPS (see ERRMSG macro 
instruction discussion) . 

For example,, if, at the last checkpoint, 
the input sequence number of the last mes- 
sage successfully received and processed by 
the LPS for terminal Z is 25, and after the 
restart terminal Z resends message 24, the 
operator should be notified that this mes- 
sage has already been processed by the LPS. 
If he would also resend message 25, he 
would receive a siirilar notification. When 



110 



message 26 is sent,, processing of messages 
from this terminal proceeds as if there had 
never been an interruption. 



the routine returns control to the user to 
permit him to close the line group and mes- 
sage queues data sets. Deactivation of the 
system proceeds in the following manner. 



SYSTEM DESIGN CONSIDERATIONS 



Checkpoint does not terminate incoming 
activity at the CPU before taking the 
checkpoint record. Some of the messages 
checkpointed will therefore be partially 
received. These partially received mes- 
sages as well as the messages received 
after checkpoint time must be retransmitted 
by the user after restart. 

Messages on the DASD at restart that 
have not been completely sent to their re- 
spective terminals or process queues will 
be sent starting with the header segment 
whether or not the header segment had been 
sent before the checkpoint. 

Lines in initiate or conversational mode 
at checkpoint time will be in normal mode 
upon restart,. 

Lines stopped at checkpoint time will 
remain stopped upon restart. 



Dial Line Considerations 



If a line group has more than one dial 
line, there must be at least one TERM entry 
in the terminal table for every line in the 
line group. That is, there must be an 
entry for each line in the line group each 
specifying a different relative line num- 
ber. These may be dummy entries specifying 
the DCB and relative line nuirber. If this 
is not done, checkpoint/restart will not 
function properly. 



When the system is to be deactivated,, a 
CLOSEMC macro instruction must be issued in 
a program other than the message control 
program,. A recommended procedure is to 
send a special message to a process queue 
from which a message processing program 
containing a user-written termination rou- 
tine may obtain the message. 



Note ; The CLOSEMC macro instruction may 



not be issued in the message control pro- 
gram under any circumstances. 



This termination routine should do the 
following: 

1. Be sure all other message processing 
programs and all their QTAM data sets 
are closed. 

2. Issue the CLOSEMC macro instruction 
(only one CLOSEMC is required to deac- 
tivate the entire system) . 

3. Close the MS destination and MS pro- 
cess queues data sets and any other 
data sets opened in that message pro- 
cessing program. If the processing 
program does not require a main 
storage queue data set, a dummy one 
must be supplied and opened. When 
this data set is closed, the message 
processing program requests the mes- 
sage control program to close down. 

4. Issue a RETURN macro instruction in 
order to end the message processing 
job,. 



DEACTIVATING THE TELECOMMUNICATIONS SYSTEM 



In order to terminate operation of the 
telecommunications system, the communica- 
tion line group, checkpoint,, and direct 
access message queues data sets must be 
closed. Before they may be closed,, all 
message traffic in the systeir must cease. 
To accomplish this, the user issues a 
CLOSEMC macro instruction in a user-written 
termination routine which is contained in a 
processing program. CLOSEMC controls and 
monitors line activity and checks the sta- 
tus of all data sets opened in the message 
processing programs. When all data sets 
opened in the message processing programs 
are closed,, and line activity has ceased, 



When the QTAM termination routine that 
is called by the CLOSEMC macro is entered, 
the following action occurs. Outgoing mes- 
sage traffic continues on any lines that 
are not currently receiving messages. 
Meanwhile,, incoming message traffic on each 
line is limited to the message currently 
being received over that line. When the 
last block of the current message is 
received, no more incoming messages are 
accepted (i.e., the line is not repolled or 
reenabled). As each such line becomes 
free,, any outgoing messages that have been 
queued for that line are sent. In this 
manner, incoming message traffic declines 
to nothing, while outgoing message traffic 
continues until all messages have been 
sent. 
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The QTAM termination routine monitors 
the closing of the QTAM data sets opened in 
the message processing programs. When it 
finds that all of these data sets have been 
closed,, and all outgoing message traffic 
has ended, the routine issues a STOPLN 
macro instruction for each line in the sys- 
tem. When all lines have been stopped, 
control returns to the first instruction 
following the ENDREADY macro instruction in 
the message control program. This instruc- 
tion must begin a user-written routine (or 
branch to a routine) that deactivates the 
message control program. This deactivation 
routine must issue CLOSE macro instructions 
for each of the data sets opened in the 
message control program (i.e., the line 
group, checkpoint, and direct access mes- 
sage queues data sets) . 



CLOSE Macro Instruction 



CLOSE is used in the message control pro- 
gram to deactivate any message log data 
set,, communication line groups data sets, 
checkpoint data set,, and DASD message 
queues data set the user has included in 
the telecommunications system. 



If used, this macro instruction must 
appear in a section of code following 
ENDREADY or be branched to from instruc- 
tions following ENDREADY. 

r t T - ' •*—} 

| Name | Operation J Operand | 

I. + x ) 

| [symbol] | CLOSE | Cdcba.,,,}... j 

L X X 4 



The last QTAM data set to be closed must 
be the direct access message queues data 
set. This is important, because closing 
this data set constitutes deactivation of 
the telecommunications systeir. After the 
message queues data set has been closed,, no 
further references can be made to queues, 
control blocks, terminal table, polling 
lists, etc. 



The deactivation routine should end with 
a RETURN macro instruction in order to end 
the message control job. Each of the mes- 
sage processing programs should also end 
with a RETURN. 



symbol 

the name of the macro instruction. 



deb 



specifies the symbolic address of the 
data control block for the data sets 
being closed. All message control 
data sets can be closed with one CLOSE 
macro instruction by including the 
addresses of their data control blocks 
as operands. If register notation is 
used,, the addresses of the data con- 
trol blocks must have been loaded pre- 
viously into the general registers 
specified. 
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APPENDIX A; DATA AND CONTROL FORMATS USED BY QTAM 



Entry Type 

Single 
Terminal 



Group 
Code 



Distribution 
List 



Process 
Program 



TQCBADDR 



TSEQUIN 



TSEQOUT 



T STATUS 



- 243 Bytes Maximum - 



«-8 Bytes Maximum-* 




TERMID 



User 
Area 



Direct Access 
Area 



TNTRYSZE 


TQCBADDR 




TSEQOUT 


TSTATUS 


1 1 

TERMID 
« 


Offset 


1 (f 1 

User 

Area 
1 » ! 


Direct Access 
±& 



TNTRYSZE 


TDSTRQCB 




TLISTKEY 




TSTATUS 


1 " 1 

TERMID 

« 


* 


reladdr . 


r-HJ-n 
-if- 


reladdr n 



TNTRYSZE 


TQCBADDR 


iii!iiii 


TSEQOUT 


TSTATUS 


| 1 

TERMID 




Terminal List Portion 



* Unused Field of One Byte 



Field Name 
TNTRYSZE 



TQCBADDR 



TDSTRQCB 



TSEQUIN \ 



Function 



All entry types ; 






Specifies entry size (in 
bytes) and provides 
access to the next high- 
er terminal table entry. 

Single-terminal,, group 
code, process program 
entries: Contains the 



address of the QCB for 
the queue on which out- 
going messages are 
placed. Using this 
address identification, 
the queuing routine 
places each message on 
its appropriate queue. 

Distribution List 



entries: Same function 



as for TQCBADDR, except 
that this address iden- 
tifies the QCB for a 
queue on which outgoing 
messages for a distribu- 
tion list are placed. 

Single-terminal entries : 
Stores and maintains a 
sequence number for 
incoming messages from 
the terminal represented 
by this entry. The 
SEQJN macro instruction 
uses this value as a 
check against the 
sequence number appear- 
ing in the incoming mes- 
sage header. 



Start 
Location 



byte 



byte 1 



byte 1 



byte 4 



Field 
Length 



1 byte 



3 bytes 



3 bytes 



2 bytes 



FOrm 



binary 
number 



binary 
address 



binary 
address 



binary 
count 



Value 

Provided 

By: 



macro 



iracro 



macro 



QTAM 



Value 
Range 



10-252 



0-9999 



Initial 
Value 






Figure 25. Terminal Table Entry % Formats (Part 1 of 5) 
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Field Name 
j. 

TSEQOUT 






TLISTKEY 



T STATUS 



Function 



Single-terminal, group 
code , process program 
entries : Provides and 



maintains a sequence 
number for outgoing mes- 
sages to the destina- 
tions represented by 
this entry. SEQOUT 
obtains the current 
value from TSEQOUT and 
places it in the outgo- 
ing message header. The 
sequence number is 
incremented by 1 each 
time the number is 
placed in a message. If 
a terminal is repre- 
sented by both a single 
terminal entry and a 
group code entry, only 
the TSEQOUT field in the 
group code entry is 
incremented when a mes- 
sage is transmitted via 
group code addressing. 

Distribution list entry: 



Contains the starting 
address of the termi- 
nal list portion of this 
entry, relative to the 
address of byte of the 
entry. The terminal 
list portion consists of 
subf ields reladdr^ , . - . 
reladdr n . 

All entry types : 
Indicates various 
communication condi- 
tions associated with 
the terminal (s) rep- 
resented by this entry.. 

Bits through 3 : Not 



used at present. 

Bit 1 : Interval stop 



bit; initially set to 0, 
Will remain for pro-^ 
cess or list entries. 
This bit is set to 1 
when this line is in 
INTREL mode. It is 
reset to when a 
STARTLN is issued for 
that line. 



Start 
Location 



byte 6 



byte 6 



byte 8 



Field 
Length 



2 bytes 



1 byte 



1 byte 



Form 



binary 
count 



binary 
rela- 
tive 
address 



binary 
status 



Value 

Provided 

By 



QTAM 



macro 



macro 



Value 
Range 



Initial I 
Value 



0-9999! 



see 
specif- 
ic bits I 



Figure 25. Terminal Table Entry Formats (Part 2 of 5) 
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T T 

Value 

Provided 

By: 



Field Name 



Function 



Start 
Location 



Field 
Length 



Form 



Value 
Range 



Initial 
Value 



TERMID 



Bit 5 ; Intercept bit; 



initially set to 0. 
This bit is set to 1 
upon issuing of an 
INTERCPT macro instruc- 
tion to indicate that a 
message on the queue was 
not transmitted. It may 
be reset to by a CHNGT 
or RELEASEM macro 
instruction when trans- 
mission can be resumed. 

Bit 6 : Send bit; ini- 
tially set to 1. This 
bit is set to upon 
issuing of an INTERCPT 
indicating that messages 
on the queue for the 
destination are withheld 
from transmission. It 
may be reset to 1 by a 
CHGNT or RELEASEM macro 
instruction when trans- 
mission can be resumed. 

Bit 7: Receive bit; 



initially set to 1 to 
indicate that the termi- 
nal represented by this 
entry is being polled. 
It may be set to to 
prevent polling of the 
terminal. Setting to 
or 1 is achieved by 
means of the CHGNT macro 
instruction. Note ; Bit 
7 is not applicable to, 
and is not used by, 
group code, distribution 
list and process program 
entries. 

All entry types: Con- 



tains the name of the 
terminal that this 
entry represents, in the 
form of a terminal code 
(or code for the 
process program) . 
This code is the 
same code that can 
appear in the source or 
destination code field 
of the message header. 



byte 9 



1 to 8 
bytes 



EBCDIC 
char- 
acters 
(upper 
case) 



User 



Figure 25,. Terminal Table Entry Formats (Part 3 of 5) 
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Field Name 
Offset 






User area 



Device 
access 
area 



Function 



Dial Terminal: Offset 



from the beginning of 
the entry to the code 
for the number of dial 
digits, 

Nondial Terminal: Off- 



set from the beginning 
of the entry to the 
device access field. 

Single-terminal and 
group code entries : Con- 
tains such data as the 
particular application 
may require, e.g. alter- 
nate destination codes, 
polling limit parameters 
and diagnostic informa- 
tion. The user area 
consists of a contiguous 
series of subfields 
whose form, length, and 
contents are specified 
by means of OPTION and 
TERM (see the descrip- 
tions of these macro 
instructions) . 

Single-terminal and 
group code entries : 
Nonswitched lines - 
Contains the polling and 
addressing characters 
for the terminal (s) rep- 
resented by this entry. 
These characters are 
specified by the "ad- 
dressing" operand of the 
TERM macro instruction. 

Switched lines - The 
first byte contains the 
number of dial digits; 
the next bytes contain 
the dial digits. These 
are specified in the 
operand of the TERM 
macro instruction. The 
following bytes contain 
the addressing charac- 
ters as specified in the 
TERM macro instruction. 



Start 
Location 



Immedi- 
ately 
follow- 
ing 

TERMID 



(see 
Note 1) 



Immedi- 
ately 
follow- 
ing user 
area 



Field 
Length 






1 byte 



Cumula- 
tive 
length 
of all 
sub- 
fields 
in entry 



Cumula- 
tive 
length 
of all 
sub- 
fields 
in entry 



Form 



1 binary 
integer 



As spec- 
ified by 
OPTION 
macros 



Trans- 
mission 
code 



Value 

Provided 

By: 



macro 



User 



User 



Value 
Range 



Initial] 
Value 



Figure 25, Terminal Table Entry Formats (Part 4 of 5) 
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Field Name 



reladdr 



Function 



TWX terminal - the first 
byte contains the number 
of dial digits, and the 
next bytes contain the 
dial digits, followed by 
a byte containing the 
number of ID characters. 
Next are the ID charac- 
ters that were specified 
in the operand of the 
TERM macro instruction, 
followed by a nuirber of 
reserved bytes equal to 
the number of ID 
characters.. 

WTTA terminals - the 
first byte contains zero 
and the next byte con- 
tains the number of ID 
characters followed by 
the characters them- 
selves, followed by a 
number of reserved bytes 
equal to the number of 
ID characters. 



Distribution list entr- 



ies. Contains the add- 
ress of a single-termin- 
al entry relative to the 
address of the terminal 
table (i.e., TERMTBL) . 
A halfword of zero fol- 
lows the last "reladdr" 
in the distribution 
list, indicating the end 
of that list. 



Start 
Location 



Field 
Length 
+ 



Immedi- 
ately 
follow- 
ing 

TERMID 
subf ield 






2 bytes 
per 
subf ield 



Form 



Binary 
rela- 
tive 
address 



Value 

Provided 

By: 



User 



Value 
Range 



Initial 
Value 



Note 1: 



Start location immediately follows the TERMID subf ield. Symbolic references 
may be made to the optional subfields named by OPTION iracro instructions. 

L . - 

Figure 25. Terminal Table Entry Formats (Part 5 of 5) 
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Offset to First 

Polling Character 

or Number of Optional 



TQCBADDR 


TSEQOU 


T Dial Digits 
TSTATUS TERMID 

of TERMID Fields 

— Address of Imple- 
mentation Module 


User Area 












Device Access Area 






Names of Entry 1 

Fields Enclosed \ TNTRYSZE TSEQUIN 

By Heavy Lines 1 1 1 

Address of OPCTL MACRO-, 
Address of Last Entry — i 
Checkpoint Interval — i 

1 1 " I S ' Ze 


1 ALTDEST 

\ 

1 POLLIMIT 




•' 


Number of k . . c i 

r.. . r,. ... Number of 1 

- Dial Digits i — lr . ,,, . i 

ID Characters ' 

Reserved for ' 

Dial Digits ID Characters ID Compare 




TERMTBL 


10^79068 


♦, *~ 


r '' 




(Location 57872) •> 


58400 


8| 






TWX{ 
Switched < 

Non 
Switched ' 


48 


67208 


65 


50 


0000001 1 


BOS 


27 N Y C 


10 


5 


8 3 7 15 


6|B1518DB15189| \\ 






36 


67240 


84 


79 


00000011 


NYC 


27NYP R OC S S 


15 


5 


3 7 2 9 1 


B 9 


l—Hexnotation 








36 


27272 


51 


40 


00000011 


P H \ 


27 NiY C 


10 


5 


5 10 9 2 


C 1 






32 


67304 


30 


18 


00000011 


PITT 


27 N Y C 


6 


D 


1 D6 






Messages 
for thcs? 




32 


67336 


37 


37 


00000011 


WAS 


27 N'Y C 


6 


E 


1 E 6 


L- Device Address 




32 


67368 


71 


68 


0000001 1 


C G O 


27NYP ROCS S 


12 


K 


9 K0 


are queued 


Terminal 
Entries 


32 


67400 


21 


19 


0000001 1 


M 1 L W 


27 C G O 


6 


L 


1 L 6 


by terminal 


32 


67432 


8 


8 


00000011 


O M A 


27 C G O 


6 


M 


1 M6 






32 


67464 


1 


1 


oooooooo 


S T L 


27 C G O 


6 


N 


1 N6 






32 


67464 


32 


27 


0000001 1 


RICH 


27NIYPROCSS 


12 


R 


9 R0 








32 


67496 


6 


5 


000001 1 1 


N O. R F 


27 R 1 C H 


6 


S 


1 S6 


for these 




32 


67496 


12 


10 


0000001 1 


A T L 


2 


7 R 1 C H 


10 


T 


1 T 6 


, terminals 
are queued 
by line 




32 


67496 


11 


10 


0000001 1 


B 1 R 


2 


7 R 1 C H 


6 


U 


1 U6 




32 


67496 


4 


2 


0000001 1 


N E W O 


27 R 1 C H 


6 


V 


1V6 


Group Code Entry ► 


28 


67528 




4 


00000010 


E A S T D 1 


V 27 




Z 


'I 




42,43,44,45, 




Process Program Entry ^ 


20 


67560 


1 


15 


00000010 


N Y P ROC 


S S 










Distribution List Entry ^ 


28 


67592 




18| 


00000010 


A L L D 1 V 


H Q | 


| 38 | 1 58 | 278 | | 






Fullword Boundary 

Bytes: 


\ t 

TDSTRQCB 
Field 
,0,1,2,3 


t 
TLISTKEY 
Field 
4,5,6,7 


/ • 'V 

Unused Field of One Byte^ "reladdr" Subfields \_ End of Termi 
(Terminal List Portion of Entry) (Next Locat 

8 , 9,10,11,12,13,14,15,16 ,17,18,19,20,21 122,23,24,25126,27128129,30131 


nal Table 
on is 58426) 

32,33134,35,36137138139,40,41 





•Figure 26. Example of the Terminal Table 
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Polling List for Nonswitched Lines: 



Size 



Status 



Pointer 



4 r- 



n+1 



n+2 



n+3 



•ih 



Pointer 



Null 



\^ 



Omitted for Output -only Lines. 



Polling List for Switched IBM 1050: 



Size 


Status 


Null 


PC 


PC 



Omitted for Output-only Lines 



Polling List for TWX (AT&T 33/35) Lines: 



Size 


Status 


Null 


Computer ID Sequence 



Omitted for Output-only Lines 



Polling list for WTTA lines: 



Size 


Status 


Null 


m 


Computer ID Sequence 



LEGEND: 

Size: Indicates total length of polling list. 

Status: Indicates current status of the polling list: if nonzero, the list is active (the line can be 

polled [nonswitched line] or enabled [switched line]). The status byte is initialized to X'01 ' 
(active) when the POLL macro instruction is assembled. 

Pointer, through Pointer : Represent the addresses, relative to the terminal table address, of the first 

byte of the terminal table entries associated with this list. 

Null : Identifies the end of Ihe polling list (nonswitched lines) or identifies the list as being for a 
switched line. Null is a full byte of binary zeros. 

PC : Is a polling character to be sent to an IBM 1050 terminal that calls the computer on the line 
represented by this polling list. 

Computer ID Sequence: Is the sequence of characters to be sent to any TWX terminal that calls the 
computer on the line represented by this polling list or to be sent to a WTTA 
terminal during an identification exchange, 
m: Is the number of characters in the computer ID sequence. 



•Figure 27. Polling List Formats 
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Polling List for Auto Poll Lines after open DASD time. 
12 3 4 



SIZE 


STATUS 


TE 


AE 


PS 


PC 
o 


'o 


PC, 


'l 




PC n 


'n 


X'FE' 


Offset 



LEGEND 
SIZE: 



Indicates length of polling list. 



STATUS: Indicates current status of polling list: If nonzero, the list is active ( the 

line can be polled ). The status byte is initialized to X'01 ' (active) when 
the POLL macro instruction is assembled. 

TE: Total entries in the list. 

AE: Same value as in TE. 

PS Bits 0-2 = 010 for IBM 1030 

= 011 for IBM 1050, 1060, 2740 Types UI or EZ 
3-7= 10000. 

PC: Polling characters (one for IBM 1030, two for IBM 1050, 1060, 2740 Types 

UI or EZ). 

I: Index character associated with preceeding polling characters (The POLL macro 

generates 1 for l Q , 2 for I], and n + 1 for l n . ) 

X'FE': Scan stop byte used to find the end of the list. 

Offset: A two-byte field used to find the heading of the list from the end of the list. 



Figure 28. Auto Poll Polling List Format 
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First 8 bytes are not placed 
on direct access queue 



1 



8 9 10 



Relative offset of entry from the first entry in the terminal table 



11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 



27 28 29 30 31 



QCB 
Address 
FQUEUE 



r 

Key FKEY 



Link 

Address 

MSQUNK 



r 

Buffer 

Scheduler 

Priority 

MSPRI 



Source 

Key 

TTSKEY 



Segment 

Size 
MSEGSZE 

31 



' Message 
Address 
on DASD 
MSLCB 



Next 
Segment 

Link 
MSLINK 



MSTATUS** 
Stored Scan Pointer MSPTR 
Set to the last character of 
last processed field in header 



Previous 

Header 

Link 

MSHEAD 



Next 

Header 

Link 

MSDLINK 



Destin - 
ation 
Key 

TTDKEY 



J 



Message Sequence Number (IN) MSNUMI 

Message Sequence Number (OUT) MSNUMOUT-— ' 



HSA0& P8€FiX 


HEADER 
HDSTRT 


TEXT (Optional) 



Format of Buffer containing Header 
First 8 bytes are not placed 
on direct access queue 



1 



8 9 10 11 12 13 14 15 16 17 18 19 20 21 



QCB 
Address 
FQUEUE 



Key FKEY, 



Link 

Address 

MSQLINK 



Source 

Key 
TTSKEY 



k Message 
Address 

on DASD 
MSLCB 



Buffer 


Segment 


Scheduler 


Size 


Priority 


MSEGSZE 



T 
MSTATUS ** 



Next 
Segment 

Link 
MSLINK 



Message 
Header 

Link 
MSHEAD 



MSPRI 



21 



TEXT PREFIX 



TXSTRT 



TEXT 



Format of Buffer containing Text 

* or the address of the LCB associated with this buffer. 

** Significance of the bits in the MSTATUS bytes is as follows: 



Bit Position Bit Name 



CANCEL 



Meaning 



= Send or process message 

1 = Do not send or process message 



REROUTE = Original copy of header 
1 = Duplicate copy of header 



2 EOB = No EOB is present in any buffer position except the last 

1 = An EOB is present in some buffer position other than the last 

(Presence or lack of an EOB in the last position does not affect setting of bit) 

3 SRVCD = Message was not previously serviced 

1 = Message was previously serviced 

Note: "Serviced" is set to indicate that a message header has been read from the disk before being transmitted 
to a terminal or before being handled by a message processing task. 

4 TRUNC Not used by QTAM. 

5 PRIORITY = Message sent without priority 

1 = Message sent with priority 

6-7 SEGTYP 00 = Header segment (Not last segment) 

01 = Text segment (Not last segment) 

10 = Header segment (Last segment) 

1 1 = Text segment (Last segment) 

Figure 29. Formats of Filled Buffers 



Appendix A 121 



APPENDIX B; SUMMARIES OF OTAM MACRO INSTRUCTIONS 



Name 



[symbol] 



Operation 
CLOSE 



Operand 

(dcb iw „ dcb2«f m * • • 5 



deb 

(DASD message queues) 



DCB 



keyword operands 



deb 
(checkpoint) 



DCB 



keyword operands 



deb 

(line group) 



DCB 



keyword operands 



deb 

(message log) 



DCB 



keyword operands 



ENDREADY 



+— 



[symbol] 



OPEN 



( Cdcbi, [ ( 

I", MF=L 
|_ f MF=(E f 



INPUT 



OUTPUT 
INOUT 



[, IDLE] )],}...) 



listname) 



Figure 30. Summary of Data Set Definition,, Initialization, and Deactivation Macro 
Instructions 
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Name 



Operation 



4- 



Operand 



Function of Macro Instruction: 



Buffer Assignment 



I 
H 



1 

|. -h 

Polling List Definition t| | 

|. ^ 



Terminal Table Definition — ^ 

V 



+-+H 



V 



BUFFER 



Y 

symbol 

I- 

subfield 

pollname 



4- 



nnn, length 

[,mmm] 

[,BRB] 



i— +-M 



DLIST 

OPTION 

POLL 



entry 

typelength 
(entry Xl . . . ) 



i 



[, AUTOPOL=| 



ipolladdr 
nid 



\Y) 



+—+--M 



symbol 



PROCESS 



[EXPEDITE] 



f— +--M 



symbol 



TERM 



qtype, deb, r In 
[, adchars] [, (opdata,, ....)] 
r f CALL=integeri( , ID=hexchars] 
L, CALL=NONE J 






TERMTBL 



entry [ , (n) ] 

[„OPCTL=chars] [ f CPINTV=integer] 

[ , CKPART= integer] 



.J.-X- 



*-OPTION must directly follow TERMTBL macro instruction. 
2 TERMTBL must be the first of the macro instructions used to create a 
terminal table. 

Figure 31. Summary of Control Information Macro Instruction 
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Functional Macro Instructions and the Delimiters Each May Follow 



J. 








R|R]EjSjSJEJ 
C j | C j N j E j E | N | 


j Operation 




Operand 




V j V j D j N | N ] D | 

S|H|R|D|D|S| 
E | D | C j S | H j E j 
G|R|V]E|D|N| 


| BREAKOFF 


-+- 




f 


1 1 1 G | R | D j 
_._ + + J. + + 1 

* 1 1 1 I 1 1 


nnnnn 


| CANCELM 




mask 




1 1*1 1 1 i 


| COUNTER 




field 




• 1 • j 1 • ] • 1 1 


| DATESTMP 








1*1 1 1 • 1 ] 


J. 

| DIRECT 


-+" 


^CLn'desfl 
\subfield j 


+ . 


— t + — + — + — + -I 

1*3 1 1 1 1 


| EOA 




eoa 




1*1 1 1 1 1 


| EOB 








I 1*3 1 1*1 


| EOBLC 








j 1*1 1 1*1 


\- 


-+- 


^CLn'dest^ 


+ . 


— + — 4 — + — + — + — ^ 


| ERRMSG 




mask r < subfield >, 
( SOURCE ) 

/=C message') 
\msgchar / 




i j*j j j*i 










| INTERCPT 




mask 




i i i i i*i 


I LOGSEG 




deb 
/PRIORITY') 




* i * j i*i*i i 


| MODE 




VcoNVERSE/ [ f condchar] 
< INITIATE > 
pOD2260 i 
vuserfuncy 

[ r WRT60=code] 




i*i i i*i i 



•Figure 32. Summary of Line Procedure Specification Functional Macro Instructions 
(Part 1 of 2) 
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j MSGTYPE 




typechar | 1 • 1 1 1 • 1 1 


| OPCTL 




CTLMSG=msgname j 1*1 1 1 1 1 
TERM=termname 1 1 1 1 1 1 1 
[,ALTERM=termname] 1111111 
[ ,INTRCPT=/YES) ] 1111111 
I NO J | | | ] | | | 


| PAUSE 




ctlchar, insertchar j j j 1*1 1 1 


| POLLIMIT 




Jnnn \ 11*1*1111 
(subfieldj 1111111 


| REROUTE 
| ROUTE 


-+- 


mask, (=CLn'destM 1111111 
«!subfield > 1 1 1 • 1 i 1 • 1 
(SOURCE ) 1113 111 

tn3 | 1 • 1 | J 1 | 


| SEQIN 




Cn] 1 ] • 1 1 1 1 i 


| SEQOUT 




n 11*111*11 


| SKIP 
| SOURCE 


-+- 


skipchars | 1*1 1 1*1 1 
tn] 1 1 • 1 1 1 1 1 


| TIMESTMP 




n j | • j j j | • j | 


| TRANS 




table 1*1*1 1*1*1 1 


| WRU 
L 


-X- 


1 1 1 1 1*1*1 


r i 

| Note: Restrictions qoverninq usaqe are explained in individual macro ] 
| instruction descriptions. | 



•Figure 32. Summary of Line Procedure Specification Functional Macro Instructions 
(Part 2 of 2) 
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T T 

Operation | Operand 



Name 



Restrictions 



ENDRCV 



ENDSEND 



symbol 



LP START 



Inn, ] 
TERM= 
(terinname 1# 

,INTRCPT= 



Required delimiter; must be the first 
macro instruction in an LPS. 



(YES) 
\N0 / 



POSTRCV 



Required delimiter; must immediately 
follow the last of the sequence of macro 
instructions that handle incoming 
messages. Only one POSTRCV may appear 
in an LPS. 



POSTSEND 



Required delimiter; must immediately 
follow the last of the sequence of macro 
instructions that handle outgoing mes- 
sages. Only one POSTSEND may appear in 
an LPS. 



RCVHDR 



— + 



RCVSEG 



SENDHDR 



SENDSEG 

L J. J J. J 

Figure 33. Summary of Line Procedure Specification Delimiter Macro Instructions 



Name 



| Operation! 



Operand 



Notes 



[symbol] 



CHGNP 



termname, rln. 



workarea 
=C* 0* 
=C'l' 



[symbol] 



CHNGT 



t ermn am e f wor ka r ea 



[symbol] | COPYT 



termname, workarea 



4- 



[ symbol] | COPYP 
-+- 



termname, workarea 



[symbol] | STARTLN j 



termname, j rln\ 
(ALL J 



Notes : 



1. Line activation/deactivation. 

2. Access to terminal table, polling list, or DASD queue status contents. 

3. Telecommunications system status modification. 

L . 

•Figure 34. Summary of Macro Instructions Used to Examine and Modify the Telecom- 
munications System Status 



126 



APPENDIX C: CONTROL CARD SEQUENCES FOR TELECOMMUNICATIONS JOBS 



Assembling Message Control and Message Processing Programs 

A typical control card sequence for assembling a message control or 
message processing program: 



j //ASSEMBLY 


JOB 


MSGLEVEL=1 


| //STEP1 


EXEC 


ASMFC 


| //SYS IN 
i _ _ 


DD 


* 


j_ _ _ 

1 

L 




Source Deck 


r — 

|/* 













Linkage Editing Message Control and Message Processing Programs 

A typical control card sequence for linkage editing a message con- 
trol v or message processing program: 



j //LINKEDIT JOB MSGLEVEL=1 

| //STEP1 EXEC PGM=LINKEDIT,, PARM= ■ XREF„ LET, LIST* 

|//SYSPRINT DD SYSOUT=A 

J//SYSUT1 DD DSNAME=SYS1.U,SPACE=(TRK, (30,10)), UNIT=2311 

J//SYSLMOD DD DSNAME=SYSl. JOBLIB,DISP=OLD 

J//SYSLIB DD DSNAME=SYSl.TELCMLIB r DISP=OLD 

|//SYSLIN DD * 

| 



h 

j NAME MCONTROL 

K* 

| (or) 

| NAME PROCTEST(R) 

|/* 

L 



Assembled Deck 



For message control program 



For message processing program 



Executing Message Control and Message Processing Jobs 

A typical control card sequence for executing a message control job: 



| //MSGCNTRL 


JOB 


|//JOBLIB 


DD 


| //STEP1 


EXEC 


| //SYSQUEUE 


DD 


|// 




| //DLINE 


DD 


| //BLINE 


DD 


| //XLINE 


DD 


| //WLINE 


DD 


| //LINES 


DD 


|//SYSPRINT 


DD 


J //SYSABEND 


DD 


|/* 









MSGLEVEL=1 

DSNAME=SYS1 . JOBLIB, DIS P=OLD 

PGM=MCONTROL 

DSNAME=FDISD f UNIT=2311„VOLUME=SER=222222, 

DISP=OLD,DCB=(,,BLKSIZE=84) 

UNIT=031 1050 DIAL LINE 

UNIT=032 1060 LINE 

UNIT=033 TWX LINE 

UNIT=034 WU 11 5A LINE 

UNIT=0U1 1050 LINE 

SYSOUT=A 

UNIT=2U00, LABEL= ( ,NL) 
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A typical IODEVICE macro instruction for system generation cf QTAM: 

Macro Operands 

IODEVICE UNIT=115A,,ADDRESS=034,, 
ADAPTER=TELE1 , SETADDR=2 



Subpararoeter 

UNIT=115A 

ADDRESS=034 

ADAPTER=TELE1 
SETADDR=2 



Explanation 

Western Union Polling 
Station 

IODEVICE is a communica- 
tion line (line 034) 

Telegraph adapter (Type I) 

Set Address (SAD) command 
2 specified for 115A 



Formatting the Direct Access Storage Device for Buffer-Sized Records 

The following prograir can be used to format the disk for the message 
queues data set. In this particular case, the records will be 112 
bytes long to accommodate buffers of 120 bytes. 



WRITEMSC 


5 CSECT 






SAVE 


(14,12) 




BALR 


2,0 




USING 


*»2 




ST 


13,SSS+4 




LA 


13, SSS 




OPEN 


(DCB, (OUTPUT)) 


WRITE 


WRITE 


DECB,SF, DCB, AREA 




ST 


15 , SAVE 




CHECK 


DECB 




L 


15 , SAVE 




CL 


15, EIGHT 




BE 


CLOSE 




B 


WRITE 


CLOSE 


CLOSE 


(DCB) 




L 


13,SSS+4 




RETURN 


(14,12) 


SAVE 


DS 


F 


DCB 


DCB 


DSORG=PS , MACRF= (WL) m DDNAME=MSGQUE< 
RECFM=F,DEVD=DA 


AREA 


DC 


30 0C • 


SSS 


DS 


18F 


EIGHT 


DC 


F t 8 . 




END 


WRITEMSG 



Once this program is assembled and linkage edited., it should be run 
with the following job control language to format the disk: 

//MSGCNTRL JOB MSGLEVEL=1 

//JOBLIB DD DSNAME=SYS1.J0BLIB,UNIT=2311,,DISP=0LD 

//STEP1 EXEC PGM=WRITEMSG 

//MSGQUE DD DSNAME=FDISD,UNIT=2311,SPACE= (TRK„ (25) ) , 

// VOLUME=SER=llllll,DISP=(NEW, CATLG) , 

// DCB=(,BLKSIZE=112) 



//SYSPRINT DD 



SYSOUT=A 
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APPENDIX D: QTAM REGISTER USAGE 



Certain of the registers used by QTAM may 
be of value to the user who writes open or 
closed subroutines to be included in an 
LPS. The usage of each of these registers 
is explained in this appendix. For further 
information see the section Methods of 
Including the Subroutine. 



the first data character in the header is 
located 32 bytes beyond the buffer address. 
If the buffer contains a text segment, the 
first data character is located 22 bytes 
beyond the buffer address. Both offsets 
are relative to register 6 as the base 
register. 



Register 1 — QTAM Parameter Register 



Register 2 — QTAM Parameter Register 



Register 4 — LCB Address Register 



Register 4 contains the address of the line 
control block for the line over which the 
current message was received (input LPS 
processing) or sent (output LPS 
processing) . 



Register 5 — Scan Pointer Register 



Register 5 points to the last character of 
the last header field scanned, or to the 
first blank character following that field. 

1. Register 5 contains the address of the 
last character of the field if the 
operand of the last macro that 
referred to the field either does not 
permit any variation in the length of 
the field (e.g., MSGTYPE C'A' ) r or 
specifies explicitly the length of the 
field (e.g., SOURCE 6). 

2 . Register 5 contains the address of the 
first blank character that follows the 
field if the operand of the last macro 
that referred to the field does not 
explicitly specify the length of the 
field (e.g., SOURCE [blank operand]). 



Register 6 — Buffer Address Register 



Register 6 contains the address of the buf- 
fer currently being processed by the LPS. 
"If the buffer contains a header segment, 



Register 7 — LPS Routine Base Register 



Register 7 contains the address of the 
beginning of the LPS currently being 
executed (i.e.„ points to the LPSTART macro 
expansion) . 



Register 8 — Terminal Table Source Entry 



In the Receive portion of the LPS, register 
8 contains the address of the TERM entry 
for the terminal from which the currently 
processed message was received. In the 
Send portion of the LPS„ register 8 con- 
tains the address of the TERM entry for the 
terminal to which the currently processed 
message is to be sent. 



Register 11 — End-of-Segment Address 
Register 



Register 11 contains the address of the 
last character position in the buffer cur- 
rently being read into or out of. 



Register 1H — Return Register for 
First-Level Routines 



Register 14 contains: 

1. The address of the parameter list for 
the preceding macro instruction (fol- 
lowing the BALR instruction) . 

2. The address of the next instruction 
following the macro instruction, if 
that macro has nc parameter list. 
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APPENDIX E; SUMMARY OF OPERATOR CONTROL MESSAGES 



CONTROL 
MESSAGE 


OPERANDS 


WRITTEN AS 


Dec 
Dig 


Rel 
Exp 


Hex 
Char 


w/s 


CHNGT 


term name 




X 






data 






X 




COPYC* 


term name 




X 






COPYT* 


term name 




X 






INTERCPT 


term name 




X 






INTREL 


term name 




X 






RELEASEM 


termname 




X 






STARTLN 


term name 




X 






ALL 








X 


STOPLN 


termname 




X 






ALL 








X 


SWITCH 


(no operands) 











* A response message is returned to the operator control terminal . 

Note : The Control Message ID (ctlmsg) is the same for all operator 
control messages. 

•Figure 35. Summary of Operator Control Messages 
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APPENDIX F: FORMAT AND SUMMARY OF MACRO INSTRUCTIONS 



A format illustration accompanies each macro instruction description in 
this publication. The illustrations indicate which operands must be 
coded exactly as shown, which are required, which are variable, etc. 
The conventions stated to describe the operands are as follows: 

1. Keyword operands are described either as the single word that must 
be coded as shown or by a three-part structure that consists of the 
keyword operand, followed by an equal sign (both of which must be 
coded) , followed by a value mnemonic or a coded value. 

Examples : a. ALL 

b. TYPE=PQ 

2. Positional operands are described by a lowercase name that is mere- 
ly a convenient reference to the operand and is never coded by the 
programmer. The programmer replaces the positional operand by an 
allowable expression. Expressions allowed are indicated at the 
left of the fold-out page. The chart shows what expressions are 
allowed for each operand. 

3. Uppercase letters and punctuation marks (except as described in 
these conventions) represent information that must be coded exactly 
as shown. 

4. Lowercase letters and terms represent information that must be sup- 
plied by the programmer. More specifically, "n" indicates a decim- 
al number, "nn" a decimal number with at most two digits, "nnn" 
with at most three digits, etc. 

5. An ellipsis (a comma followed by three periods) indicates that a 
variable number of items may be included. 



{ } 
[ ] 



Options contained within braces represent alternatives,, 
one of which irust be chosen. 

Information contained within brackets represents options, 
one of which may be included depending on the require- 
ments of the program. 

Underlined elements represent an assumed value in 
the event a parameter is omitted. 
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Abbreviations used in Foldout Chart 

Abbreviations Meaning 

DEC DIG Any decimal digits, up to the value indicated in the 

associated macro instruction description. 

REGISTER A general register, always coded within parentheses, 

as follows : 

(2-12) -one of general registers 2 through 12„ previously 
loaded with the right-adjusted value or address 
indicated in the macro instruction description. The 
unused high-order bits must be set to zero. The 
register may be designated literally or 
symbol ic al ly . 

(1) -general register 1, previously loaded as indicated 
above. The register can be designated only as (1). 

RX type Any address that is valid in the RX form of instruc- 

tion (e.g., LA) may be designated. 

REL EXP A relocatable expression (acceptable as an A-type or 

V-type address constant by the assembler) . 

ABS EXP An absolute expression as defined by the assembler: 

self-defining terms (decimal* hexadecimal^ binary,, 
character) , length attributes, absolute symbols, 
paired relocatable terms in the same CSECT„ and 
arithmetic combinations of absolute terms. 

CHAR A character string (the framing characters „ C* ', 

are not coded unless specifically indicated in the 
individual macro instruction description) . 

HEX CHAR Hexdecimal characters . An X in this column indi- 
cates that no framing characters and quotes are 
coded. An F in this column indicates that framing 
characters and quotes are coded. 

W/S Written as shown. 
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WRITTEN AS 




Dec 
Dig 


Register 


RX 
Type 


Rel 
Exp 


Abs 
Exp 


Char 


Hex 

Char 


W/S 




(2- 
12) 


0) 
















F 


F 






X 




















X 




















X 




















X 




















X 


































F 








X 






X 












X 


X 




















X 




X 






























X 




















X 






X 






X 














X 




X 
















X 






X 














X 






X 












X 


X 




















X 




X 
















X 






X 














X 




X 
















X 






X 














X 




X 






















X 











MACRO 
INSTRUCTION 


OPERANDS 


WRITTEN AS 


Dec 
Dig 


Register 


RX 
Type 


Rel 
Exp 


Abs 
Exp 


Char 


Hex 
Char 


W/S 


(2- 
12) 


(1) 


DIRECT 


dest 










X 










subfield 










X 










DLIST 


entry 










X 










DTFQT 


all operands 


Refer to Macro Description 


EOA 


eoa 














F 


F 




ERRMSG 


mask 
















F 




dest 










X 










subfield 










X 










SOURCE 


















X 


message 














F 






msgchar 








X 












INTERCPT 


mask 
















F 




LOGSEG 


deb 






X 




X 










LPSTART 


nn 


X 


















TERM= 










X 










MODE 


PRIORITY 


















X 


CONVERSE 


















X 


INITIATE 


















X 


MOD2260 


















X 


userfunc 










X 










condchar 














F 


F 




WRT60=code 


Refer to Macro Description 


MSGTYPE 


typechar 














F 


F 




OPCTL 


CTLMSG= 










X 










TERM= 










X 










ALTERM= 










X 










INTRCPT= 


Refer to Macro Description 



MACRO 
INSTRUCTION 


OPERANDS 


WRITTEN AS 


Dec 
Dig 


Register 


RX 

Type 


Rel 
Exp 


Abs 
Exp 


Char 


Hex 
Char 


W/S 


(2- 
12) 


(1) 


OPEN 


deb 




X 






X 












INPUT 


















X 


OUTPUT 


















X 


INOUT 


















X 


IDLE 


















X 


MF=L 


















X 


MF= 


Refer to Macro Description 


listname 












X 








OPTION 


typelength 












X 








PAUSE 


ctlchar 
















F 




insertchar 
















F 




POLL 


entry 










X 










AUTOPOL= 


Refer to Macro Description 


polladdr 
















X 




nid 
















X 




POLLIMIT 


nnn 


X 


















subfield 










X 










PROCESS 




Refer to Macro Description 


REROUTE 


mask 
















F 




dest 














F 






subfield 










X 










SOURCE 


















X 


ROUTE 


n 


X 


















SEQIN 


n 


X 


















SEQOUT 


n 


X 


















SKIP 


skipchrs 


X 












F 


F 




SOURCE 


n 


X 


















STARTLN 


termname 




X 










X 






rln 


X 


X 
















ALL 


















X 



MACRO 
INSTRUCTION 


OPERANDS 


WRITTEN AS 


Dec 
Dig 


Register 


RX 
Type 


Rel 
Exp 


Abs 
Exp 


Char 


Hex 
Char 


W/S 


(2- 
12) 


(') 


TERM 


qtype 


Refer to Macro Description 


deb 










X 










rln 


i X 


















adchars 
















X 




opdata 


Refer to Macro Description 


CALL= 


Refer to Macro Description 


ID= 
















X 




TERMTBL 


entry 










X 










n 


X 


















OPCTL= 














X 






CPINTV= 


X 


















CKPART 


X 


















TIMESTMP 


n 


X 


















TRANS 


table 


Refer to Macro Description 


WTTA 
MACROS 




Refer to Macro Descriptions 
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APPENDIX G: QTAM TERMINAL CODES 



This appendix contains charts that define 
the character sets and trans irission code 
bit patterns used by the various terminals 
supported by QTAM. Charts are also pro- 
vided that facilitate reading the terminal 
code found in storage. 



QTAM CHARACTER SET AND CODE CORRESPONDENCE 
CHART 



code bit patterns. Column 34 repeats the 
EBCDIC code presented in column 3, for ease 
of reference. 

In the EBCDIC group,, the bit patterns 
and characters are arranged in collating 
sequence from hexadecimal 00 to hexadecimal 
FF. In the remainder of the chart, the 
locations of bit patterns and characters 
are determined by the arrangement of the 
translate tables. 



This chart shows the character set and bit 
patterns for the Extended Binary Coded 
Decimal Interchange Code (EBCDIC) , and the 
character sets and transmission code bit 
patterns for each of the terminal types 
supported by OS QTAM. 

The chart may be used to determine the 
bit patterns, as contained in main storage 
bytes, for each of the various characters 
sent or received by a specific terminal 
type; and to determine the relationships, 
as established by the arrangement of the 
IBM-provided translate tables, among the 
character sets for the various terminal 
types. 

For convenience in referring to particu- 
lar chart locations, the chart's columns 
and rows are given reference numbers . Com- 
bined, these numbers enable reference to a 
particular chart location; e.g., location 
21/17, the intersection of row 21 and 
column 17, contains NL. 



Arrangement of Chart 



The chart contains a group of three columns 
for the EBCDIC character set and a group 
for each of the various terminal character 
sets. Within the EBCDIC group, column 3 
contains the 256 bit patterns comprising 
the code. For those bit patterns to which 
characters are currently assigned, the 
characters appear in column 1 (graphics) 
and column 2 (line controls and device con- 
trols) . (All currently assigned characters 
are shown, regardless of whether they are 
in the character sets of any of the termi- 
nal types represented in the remainder of 
the chart. ) 

Each of the remaining groups (columns 4 
through 34) contains the characters com- 
prising the character set of a specific 
terminal type, along with the transmission 



Terminal Character Sets 

This chart shows only the characters com- 
prising the commonly used character set 
options. The options represented in the 
chart are: 

Terminal Option 

IBM 1030 Standard and "H" options 

IBM 1050 System/360 option 

IBM 106 Standard option 

IBM 2260 Standard option 

IBM 2740 System/360 option 

AT&T 83B3 "A" and "C" options 

W U 11 5A "A" and "c" options 

ATST TWX Standard option 

WTTA Standard option 

IBM 1030 graphics and AT&T 83B3/WD 115A 
graphics that differ for the respective 
options are indicated in the chart by S and 
H, and A and C„ respectively. Graphics not 
so marked are the same in both options. 

Transmission Codes 



The notations in the code columns of the 
chart for the various terminal types repre- 
sent the System/36 byte bit pattern equiv- 
alents of the applicable transmission 
codes. The applicable transmission codes 
are: 

Terminal Code 

IBM 1030 Perforated tape and transmis- 
sion code 
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IBM 1050 Perforated tape and transmis- 
sion code 

IBM 1060 Perforated tape and transmis- 
sion code 

IBM 2260 IBM 2260 transmission code 

IBM 2740 Perforated tape and transmis- 
sion code (BCD code) 

AT6T 83B3 5-level Baudot code 

W U 115A 5-level Baudot code 

AT&T TWX 8-level TWX code 

WTTA 5-level ITA2 code 

5-level ZSC3 code 



Representation of Characters and Bit 
Patterns 



Appearance of a character and its asso- 
ciated bit pattern in a character set sig- 
nifies that the appropriate IBM-provided 
translate tables effect either incoming 
translation (i.e.,, translation of that 
character to the corresponding EBCDIC char- 
acter) , or outgoing translation (i.e., 
translation of the corresponding EBCDIC 
character to that character) , or both. How 
the bit pattern appears indicates which of 
these cases applies: 

1. Where the hexadecimal representation of 
the bit pattern appears in brackets, 
only incoming translation is performed. 

2. Where the bit pattern is enclosed in 
parentheses, only outgoing translation 
is performed. 

3. Where the bit pattern is not enclosed 
by brackets or parentheses, both incom- 
ing and outgoing translation are 
performed. 

Because each unique bit pattern for a ter- 
minal character can be represented only 
once in an "incoming" translate table, the 
character associated with the bit pattern 
can be translated to only one EBCDIC char- 
acter. The converse is not true, however; 
any one transmission code bit pattern can 
be placed any number of times within an 
"outgoing" translate table. Therefore, any 
number of EBCDIC characters can be trans- 
lated to the terminal character represented 
by that bit pattern. 

Appearance of two bit patterns opposite 
a single character signifies that the char- 
acter has both an upper- case and a lower- 
case bit pattern, and that both forms of 



the character are translated to the same 
EBCDIC character. 

Exampl e : The bit pattern of the NL charac- 
ter appears in location 21/9. Both the 
lower- and upper-case bit patterns of this 
character are translated to the EBCDIC NL 
character when they appear in an incoming 
message. When an EBCDIC NL character 
appears in an outgoing message, QTAM trans- 
lates it to the lower-case form of the NL 
character. 

Where more than one EBCDIC character 
requires translation to the same character 
in a terminal character set, the terminal 
character appears an equivalent number of 
times in the column (e.g., locations 0/23, 
6/23, 7/23„ 26/23, and 50/23 all contain 
the LTRS character) . 

Where a character appears in both the 
graphics and the controls columns for a 
terminal type, its function depends on 
whether it is sent when the line is in con- 
trol mode or in text mode. Depending on 
the type of terminal and the mode* the 
character may perform a control function,, 
print as a graphic, or both. For details,, 
see the reference manuals for each of the 
various terminals. 



Nonequivalent Characters 



Designing the system to accommodate termi- 
nal types having different character sets 
and control functions has resulted in sev- 
eral instances where dissimilar characters 
have been "equated" in translate tables. 
This accounts for the appearance in certain 
rows of this chart of non- equivalent char- 
acters, for example, in rows 3, 38<, and 50. 

In other instances, the same or similar 
functions have different names among the 
various terminal types; for example, HT and 
Tab in row 5 are equivalent, as are DEL and 
Rubout in row 7. 

In a few instances, terminals using the 
same transmission code have different mean- 
ings assigned to the identical bit pattern; 
for example, bit pattern 79 in the trans- 
mission code has the meaning PF for an IBM 
1050„ and Subtract for an IBM 1060,. 



Substitutions 



Where blank positions appear in the termi- 
nal character set portion of the chart, 
there is no equivalent character for the 
EBCDIC character or bit pattern at the left 
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of the chart. Where these blanks appear, 
the SUB character is to be assumed (they 
were omitted to make the chart more read- 
able) . That is, in each translate table 
that handles incoming messages, each posi- 
tion representing an invalid transmission 
code bit pattern (that is, one not used by 
a character in the terminal's character 
set) contains the EBCDIC code (3F) for the 
SUB character. In each translate table 
that handles outgoing messages, 

1. each position that represents an in- 
valid EBCDIC bit pattern (a pattern to 
which no EBCDIC character has been 
assigned) , and 

2. each position that represents a bit 
pattern for a character having no 
equivalent in the destination ter- 
minal 's character set 

contains the transmission code bit pattern 
for a substitute graphic. For the IBM 
1050, 2260, and 2740, and the ATST 83B3 and 
WU 115A, this substitute character is a 
colon (:).. For the IBM 1030 and 1060, and 
the ATST.TWX, it is a slash (/). 



General Notes 



1. Standard abbreviations are used to 

represent the control characters. The 
full names of the characters are 
given. For descriptions of these 
characters, see the reference manuals 
for the various terminals. 



option 10 30, the translate table may 
be used as is, and similarly, for the 
83B3/115A,, with respect to the C 
option. If messages from terminals 
with the H or C cption are to be 
exchanged with other terminal types, 
the user may wish to modify the 
tables. 

5. Some TWX terminals send even-parity 

transmission- code bit patterns; others 
send nonparity bit patterns. All bit 
patterns sent by nonparity machines 
have a ' 1* in the low-order bit posi- 
tion (that is, the position that 
serves as the parity bit in even pari- 
ty machines). The RCVTWX translate 
table translates either a non-parity 
or an even parity bit pattern to the 
EBCDIC bit pattern for the correspond- 
ing character. For those characters 
whose even parity and nonparity bit 
patterns are identical, a single bit 
pattern appears in column 30 of the 
chart. For example, a single pattern, 
X'C3', appears in location 195/30. 
For those characters whose even parity 
and nonparity bit patterns differ by 
the setting of the low-order bit, two 
bit patterns appear* as for example, 
in location 19 3/30. Where two bit 
patterns appear, the one enclosed in 
brackets ( [ ] ) is the nonparity bit 
pattern. The brackets indicate that 
the nonparity bit patterns are only 
received from TWX terminals. In out- 
going message transmission, the 
SNDTWXE translate table sends even 
parity bit patterns, while the SNDTWXO 
translate table sends nonparity bit 
patterns. 



2. "Circle" characters ( B , D , etc.) 
in the chart are alternate names for 
the characters after which they 
appear. 

3. Notes pertaining to specific charac- 
ters or bit patterns are indicated by 
superscript numerals next to the char- 
acter or bit pattern. The notes fol- 
low, and indicate the chart locations 
to which they apply. 

4 . Most of the characters in the S and H 
character set options (1030) and in 
the A and C character set options 
(83B3, 115A) are identical. Where 
they differ between the options, the 
translate tables favor the S option 
and the A option, as illustrated in 
the chart. If messages from an H 
option 1030 are sent only to another H 



Notes : 

s-Left bracket translates to EBCDIC hex 79; 
no EBCDIC character has been assigned to 
this bit pattern (location 121/3, 121/28). 

2 No graphic prints in the A character set 
option (location 90/22). 

3 Backslash translates to EBCDIC hex El; no 
EBCDIC character has been assigned to this 
bit pattern (locations 225/3, 225/28). 

U IBM 1031 sends the numeric as a hex 20; 
1033 receives the numeric as a hex 15 
(location 240/4). 

5 Right bracket translates to EBCDIC hex 49; 
no EBCDIC character has been assigned to 
this bit pattern (locations 73/3,„ 73/28). 



Appendix G 137' 



Control Characters 



IGS 



Interchange group separator 



IL 



ACK 



Positive Acknowledgement 



(§> 


End-of-block 
(same as EOB) 


IRS 
IUS 


BEL 


Bell 


LC 


BS 
BYP 

© 


Backspace 

Bypass 

End-of -transmission 
(same as EOT) 


LF 

LF-CR 
LTRS 
MZ 


CAN 


Cancel 


® 


cc 

CR 

® 


Cursor control 

Carriage (carrier) return 

Machine end-of -address 
(same as EOA) 


NAK 

NL 

NUL 


DC1 
DC 2 
DC 4 


Device controls 


PF 
PN 


DEL 


Delete 


PRE 


DLE 


Data link escape 


PZ 


DS 


Digit select 


RES 


EM 


End of medium 


RM 


ENQ 


Enquiry 


RS 


EOA 


End-of -address 


© 


EOB 


End-of-block 


SI 


EOC 


End of card 


SM 


EOFC 


End of first card 


SMI 


EOM 


End-of -message 


SO 


EOT 


End-of -transmission 


SOH 


ETB 


End-transmission block 


SMM 


ETX 


End-of -text 


SOS 


FF 


Forms feed 


SP 


FIGS 


Figures shift 


STX 


FS 


(EBCDIC hex 22) field 


SUB 


HT 


Horizontal tabulate 


SYN 


IFS 


Interchange file separator 


Tab 



Idle 

Interchange record separator 

Interchange unit separator 

Lower-case shift 

Line feed 

Line feed-carriage return 

Letters shift 

Minus zero 

Negative response to polling, 
addressing, or LRC/VRC 

Negative acknowledgement 

New line 

Null 

Punch off 

Punch on 

Prefix 

Plus zerc 

Restore 

Record mark 

Reader stop 

Start-of -address 

Shift in 

Set mode 

Start Manual Input 

Shift out 

Start-of -header 

Start-manual-message 

Start-of-signif icance 

Space 

S ta rt - o f -t ext 

Substitute 

Synchronous idle 

Tabulate (horizontal) 
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TM 


Tape mark 


TpAuxOff 


Tape auxiliary off 


TpAuxOn 


Tape auxiliary on 


UC 


Upper-case shift 


VT 


Vertical tabulate 



WRU 



X-Off 



X-On 



•Who Are You?' 



Transmitter off 



Transmitter on 



® 



Positive response to polling, 
addressing, or LRC/VRC 
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Ref. 


























IBM 2260 




IRM 97AD 






AT&T 83 B3 






AT&T TW> 










2260 


1053 




W U 1 15A 




Character 


Cade 

(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 

(Hex) 


Character 


Code 

(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic | Control 


Graphic 


Control 


Graphic 


Control 


1 


2 


: ?"-!>fl 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


10 


19 | 20 


21 


22 


23 


24 


25 


2o 



1 

2 
3 




NUL 
SOH 
STX 
ETX 


00 
01 
02 
03 


# = 

S H 


Pad 

<D 
EOA(®) 
EOB(®) 


(DF) 
(37) 
06) 
(3D) 


# 


IL 

EOA(®) 
EOB(®) 


(5E) 

(16) 
(3D) 


# 


IL 

EOA(®) 
EOB«D) 


(5E) 

(16) • 
(3D) 




SOH 
STX 
ETX 


01 
02 
03 




SOH 
STX 
ETX 


(01) 
(02) 
(03) 


# 


IL 

© 

EOA(®) 

EOB(®) 


(5E) 
(37) 
(16) 
(3D) 




LTRS 
CR 


OF) 
(02) 




Rubout 
CR 


4 
5 
6 

7 




PF 
HT 
LC 
DEL 


04 
05 
06 
07 




HT 

Pad 

EOC DEL 


(7A) 
(DF) 
7p 




PF 
Tab 
Dwnshft 
DEL 


79 0=9] 
7aD=A] 
7CM 
7F [FF] 




Subtr 
Tab 
IL 
DEL 


(79) 
<7A) 
(5E) 
7F 
















HT 

Dwnshft 

DEL 


7A [FA] 
7C [FC] 
7F [FF] 




LTRS 
LTRS 


IF [3FJ 
(IF) 




TpAuxOff 
HT 

Rubout 


8 

9 

10 

11 




SMM 
VT 


08 
09 
0A 
0B 




















► 


Start Ml 


[CD] 


* 




(CD) 
















VT 


12 
13 
14 
15 




FF 
CR 
SO 
SI 


oc 

0D 
0E 
OF 




LF-CR 


(5B) 




NL 
BYP 
RES 


(5B) 
(38) 
(58) . 




CR 


(5B) 




NL 


(0A) 




NL 


(0A) 




NL 


(5B) 




CR 


(02) 




FF 
CR 
SO 
SI 


16 
17 
18 
19 




DLE 
DC1 
DC2 
TM 


10 

n 

12 
13 














































X-On 


20 
21 
22 
23 




RES 
NL 
BS 
IL 


14 
15 
16 
17 




LF-CR 
Pad 


(5B) 

(DF) 




RES 
NL 
BS 
IL 


58&>8J 
5B [PBJ 
5D[DDj 
5E[DE] 


• 


CR 
IL 


(58) 
(5B) 

<5E) 


A 


NL 


0A 




NL 


(0A) 




NL 
BS 
IL 


5B [DB] 
5D [DD] 
5E [DE] 




LF 
LTRS 


(08) [28] 
(IF) 




LF 
Rubout 


24 
25 
26 
27 




CAN 
EM 
C~ 
CU1 


18 
19 
1A 
IB 




















■ 


CAN 
Check 


[18] 
42 


» 




(42) 


















28 
29 
30 
31 




IFS 
IGS 
IRS 
IUS 


1C 
ID 
IE 
IF 
















































32 
33 
34 
35 




DS 

SOS 

FS 


to 

21 
22 
23 
















































36 
37 
38 
39 




BYP 

LF 
ETB (EOB) 
ESC (PRE) 


24 
25 
26 
27 




LF 
EOB((D) 


(3B) 
3D 




BYP 
LF 
EOB 
PRE 


38 [B8] 
3B [BB] 
3D [BD] 
3E [BE] 




LF 
EOB(®) 


(3B) 
3D 




ETX 


(03) 




ETX 


(03) 




LF 
EOB 


3B [BB] 
3D [BD] 




LF 
CR 


(08) 
[02] [22] 




LF 
CR 


40 
41 
42 
43 




SM 
CU2 


28 
29 
2A 
2B 
















































44 
45 
46 
47 




ENQ 
ACK 
BEL 


2C 
2D 
2E 

■;■<; 2F 






















ACK 


06 




ACK 


06 








c' 


aB.II 


3A 




WRU 
Bell 


48 
49 
50 
51 




SYN 


31 
32 
33 




Pad 


(DF) 




IL 


(5E) 




IL 


(5E) 
















IL 


(5E) 




LTRS 


OF) 




Rubout 


52 
53 
54 
55 




PN 
RS 
UC 
EOT 


34 

35 
36 
37 




EOT(©) 


If 




PN 

RS 

Upshift 

EOT(©) 


19 £9] 

lAgMg 




EOT(©) 


(IF) 




EOT ( © ) 


04 




EOT(©) 


04 




Upshft 
EOT(©) 


IC [9C] 

IF 


# 


FIGS 


IB (3B] 
(25) 




TpAuxOn 
EOT 


56 
57 
58 
59 




CU3 


38 
39 
3A 
3$ 
















































60 
61 
62 
63 




DC4 
NAK 

SUB 


3C 
3D 
3E 
3F 






(23) 






(88) 


/ 




(23) 




NAK 


15 
(5A) 




NAK 


[153 
(5A) 






(88) 


; / 




(37) 




X-Off 


64 
65 
66 
67 




SP 


41 

... ■*£>'■:'■ 

-43 v 




SP 


01 




SP 


01 m 




SP 


01 , 




SP 


40 




SP 


(40) 




SP 


01 [81] 




SP 


04 [24] 




SP 


68 
69 
70 
71 






...44..^* 

'45 V ; " 
. '47, :.■ 
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AT&T 83 B3 






AT&T TU/V 


WTTA (1TA2) 




WTTA (TSCSl 


EBCDIC 


Ref. 








2260 


1053 




W U 115A 






Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 

(Hex) 


Character 


Code 

(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code (Hex) 
Even Non 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Code 
(Hex) 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic | Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graph i c 


Control 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 | 14 


15 


16 


17 


18 


19 


20 


21 


22 


23 


24 


25 


26 


27 


28 


29 


30 


31 


32 


33 


34 


1 # = 

S H 


Pad 

© 
EOA(®) 
EOB(®) 


(DF) 
(37) 
(16) 
(3D) 


# 


IL 

EOA(®) 
EOB((D) 


(5E) 

(16) 
(3D) 


t 


IL 

EOA(®) 
EOB(®) 


(5E) 

(16) - 
(3D) 




SOH 
STX 
ETX 


01 
02 
03 




SOH 
STX 
ETX 


(01) 
(02) 
(03) 


# 


IL 

© 
EOA(®) 
EOB(®) 


(5E) 
(37) 
(16) 
(3D) 




LTRS 
CR 


OF) 
(02) 




Rubout 
CR 


(FF) (FF) 
(Bl) (BO 




LTRS 
CR 


OF) 
(02) 




LTRS 
CR 


(IF) 
(02) 


00 
01 
02 
03 



1 
2 
3 




HT 

Pad 

EOC DEL 


(7A> 
(DF) 
7F 




PF 
Tab 
Dwnshft 
DEL 


79 |M 
7AD=a] 
7C[FC] 
7F [FF] 




Subtr 
Tab 
IL 
DEL 


(79) 
(7A) 
(5E) 
7F 
















HT 

Dwnshft 

DEL 


7A [FA] 
7C [FC] 
7F [FF] 




LTRS 
LTRS 


IF [3F] 
(IF) 




TpAuxOff 
HT 

Rubout 


28 29 
90 91 

FF FF 




LTRS 
LTRS 


(IF) 
(IF) 




LTRS 
LTRS 


(IF) 
(IF) 


04 
05 
06 
07 


4 
5 
6 

7 




















► 


Start Ml 


[CD] 


<t 




(CD) 
















VT 


m di 














08 
09 
0A 
0B 


8 
9 
10 
11 




LF-CR 


(58) 




NL 
BYP 
RES 


(5B) 
(38) 
(58) . 




CR 


(58) 




NL 


(0A) 




NL 


(0A) 




NL 


(58) 




CR 


(02) 




FF 
CR 
SO 
SI 


30 31 
(Bl) (Bl) 
71 71 
FD F1 




CR 


(02) 




CR 


(02) 


OC 
0D 
0E 
OF 


12 
13 
14 
15 














































X-On 


88 89 














10 
11 
12 
13 


16 
17 
18 
19 




LF-CR 
Pad 


(5B) 
(DF) 




RES 
NL 
BS 
IL 


58EJ58J 

sops 

5D[DDj 
5£[DE] 


• 


CR 
IL 


(58) 
(5B) 


A 


NL 


0A 




NL 


(0A) 




NL 
BS 
IL 


5B [DB] 
5D [DD] 
5E [DE] 




LF 
LTRS 


(08) [28] 
(IF) 




LF 
Rubout 


[50] [51] 
(FF) 




CR 
LTRS 


02 [22] 

(IF) 




CR LF 
LTRS 


02 [22] 
(IF) 


14 
15 
16 
17 


20 
21 
22 
23 




















I 


CAN 
Check 


[18) 
42 


• 




(42) 
































' 18 
19 
1A 
IB 


24 
25 
26 
27 






























































IC 
ID 
IE 
IF 


28 
29 
30 
31 


















81888 












































20 
21 
22 
23 


32 
33 
34 
35 




LF 
EOB(d» 


(3B) 
3D 




BYP 
LF 
EOB 
PRE 


38 [B8J 
38 [BB] 
3D [Big 

3E m 




LF 
EOB((D) 


(3B) 
3D 




ETX 


(03) 




ETX 


(03) 




LF 
EOB 


38 [BB] 
3D [BD] 




LF 
CR 


(08) 
B>2] [22] 




LF 
CR 


(50) [51] 

.Bl 




LF 
LF 


08 [28] 
(08) 




LF 
LF 


08 [28] 

(08) 


24 
25 
26 
27 


36 
37 
38 
39 




















































Bell 


3A 




Bell 


2C 


28 
29 
2A 
2B 


40 
41 
42 
43 






















ACK 


06 




ACK 


06 








C 


ABell 


3A 




WRU 
Bell 


A0 Al 
£1 El 














2C 
2D 
2E 

[ 2F 


44 
45 
46 
47 




Pad 


(DF) 




IL 


(5E) 




IL 


(5E) 
















IL 


(5E) 




LTRS 


OF) 




Rubout 


(FF) (FF) 




LTRS 


(IF) 




LTRS 


(IF) 


30 
31 
32 
33 


48 
49 
50 
51 




EOT(©) 


W 




PN 

RS 

Upshift 

EOT(©) 


19 [99] 
1A [9A] 
)C[9Q 




EOT(©) 


(IF) 




EOT ( © ) 


04 




EOT(©) 


04 




Upshft 
EOT(©) 


IC [9C] 
IF 


# 


FIGS 


IB E3B] 

(25) 




TpAuxOn 
EOT 


48 49 

21 21 




FIGS 
LTRS 


18 feB] 

IF 




FIGS 
LTRS 


18 [3B] 

(IF) 


34 
35 
36 
37 


52 
53 
54 
55 






























































r 38 
39 
3A 
3B 


56 
57 
58 
59 






(23) 






(88) 


/ 




(23) 




NAK 


15 
(5A) 




NAK 


[15] 
(5A) 






(88) 


/ 




(37) 




X-Off 


C9 C9 
(5C) (5D) 


: / 




(37) 


1 / 




(2A) 


3C 
3D 
3E 
3F 


60 
61 
62 
63 




SP 


01 




SP 


o) $B$f> 




SP 


o? , 




SP 


40 




SP 


(40) 




SP 


01 [8Vj 




SP 


04 [24] 




SP 


05 05 




SP 


04 [24] 




SP 


04 [24] 


40 
41 
42 
43 


64 
65 
66 
67 






























































' 44 
45 
46 
47 


68 

69 

70 
71 
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Ref. 


EBCDIC 






















IBM 2260 




IRM 774D 






AT&T 83B3 






AT&T TW 










2260 


1053 




W U 113A 




Character 


Code 
(Hex) 


Character 


Code 

(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 

(Hex) 


Character 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


1 


2 


3 


4 


5 


6 ' 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


IB 


19 


20 


21 


22 


23 


24 


25 


26 


72 
73 
74 
75 


i 




48 
49 9 
4A 
4B 




© EOFC 


76 


* 


® 


A0 
76 




® 


(76) 






4E 






(4E) 


4- 


® 


A0 
76 






27 


] 5 




76 
77 

78 
79 


< 

( 

+ 
i 




4C 
40 
4E 
4F 








< 

( 

+ 
1 




84 
93 
El 
B7 








< 

( 
+ 
1 




5C 
48 
48 
FE 


< 

( 

+ 

1 




(5C) " 

(48) 
(4B) 
(FE) 


< 
( 

+ 

1 




84 
93 
El 
B7 


a(cV2 




3E 


< 

( 

+ 

t 




80 
81 
82 
83 


& 




50 
51 
52 
53 


S& H + 




61 


& 




61 


+ 




(61) 


& 




46 


& 




146) 


& 




61 


& 




2B 


& 




84 
85 
86 
87 






54 
55 
56 
57 
















































88 
89 
90 
91 


i 
$ 




58 

59 
5A 
58 


$ 




57-. 


1 

$ 




07 
57 


$ 




(57) 


$ 




44 


$ 




1441 


1 

$ 




D7 
57 


A 2 C l/4 

$ 




36 
32 


1 

$ 




92 
93 
94 
95 


* 
) 




5C • 
5D 
5E 
5F 








* 

) 


® 


90 
95 
87 








) 




4A 
49 
5B 
FC 


* 

) 




(4A) 
(49) 
(58) 
(FC) 


* 

) 


® 


90 
95 
87 
F6 






29 

2F 


* 

) 




96 
97 
98 
99 


/ 




60 
61 
62 
63 


/ 


® 


40 
23 


/ 


<8» 


48 
23 


/ 


% 


(40) 
23 


/ 




4D 
4F 


/ 




(40) 
(4F) 


/ 


® 


40 
23 


/ 




38 
37 


/ 




)00 
101 
102 
103 






64 
65 
66 
67 
















































104 
105 
106 
107 




EOM 


68 
69 
6A 
6ft 




© 


37 






3?> 






(37) 


- 


EOM 


41 
4C 


1 




(41) 
<4C) 




© 


37 


A, .c' 7 /8 




26 






108 
109 
110 
111 


% 
> 




«C 

6D 
6E 
6F 








% 
? 


<8> 


... ^ ........ 

CO 
8E 

A3 








% 
? 




45 

BF 

5E 
5F 


% 
? 




(45) 
(BF) 
(5E) 
(5F-) ' 


% 

>" 

? 


<Q> 


8B 
CO 
8E 
A3 


A? c'V8 




33 


% 

> 

? 




112 
113 
114 
115 






70 
71 
72 
73 
















































116 
117 
118 
119 






74, 
75 
76 

71 
















































120 
121 
122 
123 


> 


EOA 


78 
79 s 

7A 
78 


S(* H = 


EOA(®) 


16 


'# 


EOA(®) 


88 


t 


EOA(®) 


16 


\ 




5A 
43 


# 




(5A) 
(43) 


# 


EOA (®) 


88 

16 


A : c .l/8 


CR 


2E 

(02) 






124 
125 
126 
J27 


@ 




7C 
70 
7E 
7F 


S'@ .H*' 




(20) 


@ 


EOA (®) 


20 

80 
82 
96 




Add 


(20) 


<s> 




EO . v 

47 

50 


@ 




(EO) 
(47) 
(5D) 


@ 


EOA (®) 


20 
8D 
82 
96 


A 1 


cBell 


34 
31 


@ 




128 
129 
130 
131 


a 
b 

c 




80 
81 
82 
83 


A 
B 

c 




(62) 
(64) 
(67) 


a 
b 
c 




62 
64 
67 


A 
B 
C 




(62) 
(64) 
(67) 


A 
B 
C 




(Al) 
(A2) 
(A3) 


A 
B 
C 




(Al) 
(A2) 
(A3) 


a 
b 

c 




62 
64 
67 


A 
B 
C 




(18) 
(13) 
(0E) 


A 
B 

C 




132 
133 
134 
135 


d 

e 
f 

g 




84 
85 
86 
87 


D 
E 
F 
G 




(68) 
(68) 
(60) 
(6E) 


d 
e 
f 

g 




68 
68 
6D 

6E ' 


D 
E 
F 
G 




(68) 
(6B) 
(6D) 
(6E) 


D 
E 
F 
G 




(A4) 
(A5) 
(A6) 
^A7) 


D 
E 
F 
G 




(A4) 
(AS) 
(A6) 
<A7) 


d 

e 
f 

g 




68 
6B 
6D 

6E 


D 
E 
F 
G 




(12) 
(10) 
(16) 
(OB) 


D 
E 
F 
G 




136 
137 
138 
139 


h 




88 

89 
8A 
88 


H 
1 




(70) 

(73) 


h 

i 




70 
73 


H 
1 




(70) 
(73) 


H 
1 




(A8) 
(A9) 


H 
1 




(A8) 
(A9) 


h 




70 
73 


H 
1 




(05) 
(OC) 


H 
1 




140 
141 
142 
143 






8C 

8D 
8E 
8F 
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EBCDIC 
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2260 


1053 




W U 113A 








Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Character 


Code (Hex) 
Even Non' 


Character 


Code 
(Hex) 


Character 


Code 
(Hex) 


Code 
(Hex) 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


Graphic 


Control 


4 


5 


& 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


18 


19 


20 


21 


22 


23 


24 


25 


26 


... 27 -:■■ , 


28 


29 


. ,-%*■:■:■" 


31 


32 


33 


34 




© EOFC 


76 


f 


® 


A0 
76 




® 


(76) 






4E 






(4E) 


t 


® 


A0 
76 






27 


] 5 




BB SB 
74 75 






2F 






21 


48 
49 
4A 
4B 


71 
73 
74 
75 








< 

( 

+ 
1 




93 
El 
B7 








< 

( 

+ 
1 




5C 
48 
48 

FE 


< 

( 

+ 

1 




15C) 
(48) 
(4B) 
(FE) 


< 
( 

+ 

1 




84 
93 
El 
B7 


a( C 1/2 




3E 


< 

( 

+ 

t 




3C 30 
14 IS 
D4 05 
7B 7B 


( 

+ 




3E 
31 


( 

+ 




3E 
38 


4C 
4D 
4E 

4F 


76 
77 
78 
79 


s & h + 




61 


& 




„ ' ^ 


+ 




(61) 


& 




46 


& 




(46) 


& 




61 


& 




2B 


& 




65 65 








& 




/.aV' 


50 
51 
52 
53 


80 
81 
82 
83 






























































54 
55 
56 
57 


84 
85 
86 
87 


$ 




57 


1 

$ 




07 
$7 


$ 




(57) 


$ 




44 


$ 




144) 


1 

$ 




D7 
57 


a 2 cl/4 

$ 




36 
32 


I 

$ 




84 85 
24 25 














58 
59 
5A 
5B 


88 
89 
90 
91 








* 

) 


® 


90 
95 
67 
F6 








* 
) 




4A 

49 
5B 
FC 


* 

) 




(4A) 
(49) 
(58) 
(FC) 


* 

) 


® 


90 
95 
87 
F6 


A' C 3 / 8 




29 
2F 


* 

) 




55 55 
95 95 
DO 00 


) 




29 


) 




29 
2F 


5C 
5D 
5E 
5F 


92 
93 
94 
95 


/ 


<Q> 


40 
23 


/ 


<8> 


23 


/ 


<8> 


(40) 
23 


/ 




4D 
4F 


/ 




(4D) 
(4F) 


/ 


® 


40 
23 


/ 




38 
37 


/ 




B4 85 
F5 F5 


/ 




38 
37 


/ 




30" 
2A 


60 

61 

! 62 

: 63 


96 
97 
98 
99 






























































64 
65 
66 
67 


100 
101 
102 
103 




<S> 


37 






' 37 






(37) 


- 


EOM 


41 
4C 


1 




(41) 
(4C) 




<D 


37 


a, .c' 7 /8 




26 






35- -35. 






26 






26 


68 
69 
6A 
6B 


104 
105 
106 
107 








% 

>~ 

? 


® 


1 as 

CO 
8E 

A3 








% 
? 




45 
BF 

5E 
5F 


% 

>" 

? 




(45\ 
(BF) 
<5E) 
OF) ■ 


% 

>* 

? 


<8> 


8B 
CO 
8E 
A3 


a? c'5/8 




33 


% 
*- 
> 
? 




A5 A5 
FA FB 
70 7D 
FC FD 


? 




33 


? 




: 25 


6C 
6D 
6E 
6F 


108 
109 
110 
111 






























































70 
71 
72 
73 


112 
113 
114 
115 






























































74 
75 
76 
77 


116 
117 
118 
119 


S, # H = 


EOA(@) 


16 


i 


EOA(©) 


'- 16 


# 


EOA(®) 


16 


'# 




5A 
43 


# 




(5A) 
(43) 


# 


EOA (®) 


88 

16 


A : c l/8 


CR 


2E 

(02) 


# 




OB OB 
5C 5D 
C5 C5 






2E 


■ 




23 


78 
79 
7k 
7B 


120 
121 
122 
123 


s;@ .*' 




(20) 


@ 


EOA (®) 


20 
80 
82 
96 




Add 


(20) 


@ 




''•- E0 ■ 
47 
5D 


@ 




(E0) 
(47) 
(5D) 


@ 


EOA (®) 


20 

8D 
82 
96 


a" 


cBell 


34 
31 


@ 




03 03 
E4 E5 
BD BD 
44 45 


' 




34 
2F 


' 




34 
2F 


7C 
7D 
7E 
7F 


124 
125 
126 
127 


A 
B 

c 




(62) 
(64) 
(67) 


a 
b 

c 




62 
64 
67 


A 
B 
C 




(62) 
(64) 
(67) 


A 
B 
C 




(A1) 
(A2) 
(A3) 


A 
B 
C 




(Al) 
(A2) 
(A3) 


a 
b 

c 




62 
64 
67 


A 
B 
C 




(18) 
(13) 
(0E) 


A 
B 
C 




(82) (83) 
(42) (43) 
(C3) (C3) 


A 
B 
C 




08) 
(13) 
(0E) 


A 
B 
C 




(18) 
(13) 
(0E) 


80 
81 
82 
83 


128 
129 
130 
131 


D 
E 
F 
G 




(68) 
(6B) 
(6D) 
(6E) 


a 

e 
f 
g 




68 
6B 
6D 
6£ 


D 
E 
F 
G 




(68) 
(68) 
(60) 
(6E) 


D 
E 
F 
G 




"(A4) 
(A5) 
(A6) 
(A7) 


D 
E 
F 
G 




(A4) 
(A5) 
(A6) 
(A71 


d 

e 
f 

g 




68 
6B 
6D 
6E 


D 
E 
F 
G 




h) 

(10) 
(16) 
(0B) 


D 
E 
F 
G 




(22) (23) 
<A3) (A3) 
(63) (63) 
(E2) (E3) 


D 
E 
F 
G 




(12) 
(10) 
(16) 
(06) 


D 
E 
F 
G 




(12) 
(10) 
(16) 
(08) 


84 
85 
86 
87 


132 
133 
134 
135 


H 
1 




(70) 

(73) 


h 
i 




70 
? 3 


H 
1 




(70) 
(73) 
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TERMINAL CODE TRANSLATION CHART 

This chart may be used in reading the ter- 
minal code found in dumps of storage. The 
hexadecimal representation of the terminal 
code, as found in a dump, is shown at the 
side of each section of the chart. Beneath 
the terminal type is found the desired 
character to which the terminal code trans- 
lates; also shown is the EBCDIC transla- 
tion. The programmer must determine if the 
hexadecimal code in main storage represents 
EBCDIC (translated) or terminal code 
(untranslated) . 

Example : In order to translate 

1601E4CC AS011515 150201CA B1E70190 



as found in a dump, the characters are 
first separated into pairs: 



16 01 EU CC A5 01 15 15 
15 02 01 CA Bl E7 01 90 

If the terminal is an IBM 1050, the chart 
shows that the characters in storage 
translate to 

EOA SP B O S SP 

1 SP N Y C SP * 

so that the message entered at the terminal 
was, in part, 

BOS 0001 NYC * 
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M 


M 






5 






AD 


AE 










N 


N 












AE 


AF 






X 




O 


O 


X 










AF 


BO 










P 


P 












B0 


Bl 






Y 




Q 


Q 


Y 




CR 






Bl 


B2 






Z 




R 


* 


Z 




M 






B2 


B3 










S 


S 






M 






B3 


B4 










T 


T 






- 






B4 


B5 










U 


U 






- 






B5 


B6 










V 


V 












B6 


B7 






1 




W 


W 


1 










B7 


B8 






BYP 




X 


X 












B8 


B9 










Y 


Y 












B9 


BA 










Z 


Z 












BA 


BB 






LF 








LF 




] 






BB 


BC 
























BC 


BD 






EOB 








EOB 




= 






BD 


BE 






PRE 


















BE 


BF 










- 


- 












BF 



S/360 


EBCDIC 






IBM 1060 


IBM 2260 R 


IBM 2740 


AT&T 83B3 




WTTA 


S/360 


IBM 1030 


IBM 1050 






W U 1 15A 


AT&T TWX 






Byte 
(Hex) 










2260 


1053 






ITA2 


ZSC3 


Byte 
(Hex) 


























Gr Ctl 


Gr Ctl 


Gr Ctl 


Gr Ctl 


Gr Ctl 


Gr Ctl 


Gr Ctl 


Gr Ctl 


Gr Ctl 


Gr Ctl 


Gr Ctl 




CO 


PZ 




_ ® 








_ ® 










CO 


CI 


A 






















CI 


a 


B 






















C2 


C3 


C 




J 








J 




C 






C3 


C4 


D 






















C4 


C5 


E 




K 








K 




t 






C5 


C6 


F 




L 








L 










C6 


a 


G 






















C7 


C8 


H 






















C8 


C9 


1 




M 








M 




X-Off 






C9 


CA 






N 








N 




s 






CA 


CB 


















s 






CB 


CC 






O 








O 




3 






CC 


CD 










►Start Ml 


<? 






3 






CD 


CE 
























CE 


CF 






P 








P 










CF 


DO 


MZ 






















DO 


Dl 


J 




Q 








Q 




VT 






Dl 


D2 


K 




R 








R 




K 






D2 


D3 


L 
















K 






D3 


D4 


M 
















+ 






D4 


D5 


N 
















+ 






D5 


D6 


O 






















D6 


D7 


P 




1 








1 










D7 


D8 


Q 




RES 


















D8 


D9 


R 






















D9 


DA 
























DA 


DB 






NL 








NL 




C 






DB 


DC 

























DC 


DD 






BS 








BS 




; 






DD 


DE 






IL 








IL 










DE 


DF 




Pad 




















DF 


EO 


RM 








@ 


@ 












EO 


El 






+ 








+ 




Bell 






El 


E2 


S 




A 








A 




G 






E2 


E3 


T 
















G 






E3 


E4 


U 




B 








B 




, 






E4 


E5 


V 
















1 






E5 


E6 


W 






















E6 


E7 


X 




C 








C 










E7 


E8 


Y 




D 








D 










E8 


E9 


Z 






















E9 


EA 
























EA 


EB 






E 








E 




W 






EB 


EC 
























EC 


ED 






F 








F 




7 






ED 


EE 






G 








G 










EE 


EF 
























EF 


FO 







H 








H 










FO 


Fl 


1 
















SI 






Fl 


F2 


2 






















F2 


F3 


3 




1 








1 




O 






F3 


F4 


4 






















F4 


F5 


5 






















F5 


F6 


6 




- © 








- © 




/ 






F6 


F7 


7 
















, 






F7 


F8 


8 






















F8 


F9 


9 




PF 


















F9 


FA 






Tab 








HT 




«- 






FA 


FB 


















♦- 






FB 


FC 






Dwnshft 




™l 


—1 


Dwnshft 




? 






FC 


FD 


















? SI 






FD 


FE 










1 


1 












FE 


FF 






^- DEL 








DEL 




Rubout 






FF 
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APPENDIX H; EXCHANGING MESSAGES BETWEEN IBM AND NON- IBM TERMINALS 



Certain line and device control functions 
are implemented differently for IBM termi- 
nals and non-IBM terminals. Generally, no 
difficulties arise when messages are 
exchanged between IBM terminals of the same 
or different types, or between non-IBM ter- 
minals of the same type. For applications 
in which messages are to be exchanged 
between non-IBM terminals of dissimilar 
types, or between IBM and non-IBM termi- 
nals, the user should be aware of the con- 
siderations explained below, and plan his 
message headers accordingly. In some 
cases, it will be necessary to edit certain 
characters or character sequences out of 
incoming messages and edit certain charac- 
ters or sequences into outgoing messages, 
The functions concerned are: carriage 
return, new v line , line feed, end of 
address, end of block, end of transmission,, 
and 'who are you?' (the latter function 
applies to TWX and WTTA terminals) . 



End-of -Address 



For all IBM terminals except the 2740 
Types I and VI, there may be two EOAs (two 
STXs for 2260) as the first two characters 
transmitted to the terminal. The first one 
is sent by the access method that sends the 
message to the terminal, while the second 
appears in core as the first character in 
the buffer (following idle characters spec- 
ified in the LPSTART macro instruction) . 
This second EOA was sent by the terminal as 
the first character in the message. 

The EOA character transmitted by the 
access method will perform its normal func- 
tion of putting the terminal in text mode„ 
but the second EOA will print as a text 
mode character at the beginning of the mes- 
sage. The user may wish to insert the fol- 
lowing code to delete this character before 
transmitting the message: 



CLI KSKX^B' 

BNE NO 

MVI 1(5)«,X°17* 

LA 5,1(0,5) 



IS THIS EOA CHARACTER 
NO IT IS NOT 
YES, REPLACE WITH IDLE 
INCREMENT SCAN POINTER 



NO 



All QTAM-supported IBM terminals employ a 
single machine end-of -address (EOA) charac- 
ter, known as a (D) (for 226 start-of-text 
(STX) character). Of the non-IBM termi- 
nals, the 83B3 represents EOS by the 
sequence CR LF LTRS; the 115 A represents 
EOA by a single space character; and the 
TWX and WTTA terminals have no EOA 
sequence . 

If messages are to be switched from a 
non-IBM terminal to an IBM terminal, the 
user must edit out the received EOA charac- 
ter or sequence and insert the proper 
sequence for the receiving terminal. 
Figure 36 provides the code representations 
for the EOAs for each terminal type. 

Western Union 115A terminals require 
that an EOA (space) be the first character 
in the header. AT ST 83B3 terminals require 
an EOA (CR LF LTRS) as the first three 
characters in the header. The QTAM user 
cannot have idle characters in his message 
header preceding the EOA. He may ensure 
this by moving the EOA into the buffer 
beginning with byte 32. Space for the^EOA 
should be included in the bytes reserved in 
the message header by the LPSTART macro 
instruction. If TIMES TAMP, DATESTAMP or 
SEQOUT is specified, it should precede the 
movement of the EOA into the header. 



This problem should not exist for mes- 
sages generated by a message processing 
program. In this situation, the access 
method will transmit the required EOA 
sequence prior to writing the characters 
from the buffer; no other EOA should be 
present. 



Carriage Return, Line Feed, New Line, and 
End-of-Block 



For non-IBM terminals, the carriage return 
and line feed functions are performed by 
two separate characters, CR and LF. For 
IBM terminals, the functions are performed 
by the single character new line (NL) . A 
NL character in a iressage sent to a non-IBM 
terminal cannot be translated to two separ- 
ate characters, that is, to both the CR and 
LF characters. To compensate for this, 
QTAM takes advantage of the usual practice 
of sending an EOB character at the end of 
each line of text printed on the printer 
(i.e., sending an EOB followed by a NL) . 
Standard QTAM translate tables effect con- 
version of the EOB and NL characters to LF 
and CR, respectively*, for messages sent 
from an IBM terminal to a non-IBM terminal. 
Conversely, when messages are sent from a 
non-IBM terminal to an IBM terminal, CR and 



Appendix H 153 



LF characters are converted to EOB and NL 
characters. Thus, as long as any messages 
originating from an IBM terminal always use 
the EOB and NL characters in combination, 
the carriage return and line feed functions 
at the receiving terminal (non-IBM) are 
effected just as if the originating termi- 
nal had entered CR and LF into the message. 

When messages are sent from a telegraph- 
type terminal (AT&T-83B3, TWX, WTTA, or 
Western Union 115A) to an IBM 2740 Model 2 
with the Buffer Receive option, LF trans- 
lates to EOB when using IBM-supplied 
translate tables. Since (1) the contents 
of the buffer are printed only when EOT is 
received, and (2) all blocks are read into 
the same buffer, only the block received 
just prior to the EOT will be printed. 
(All previous blocks will have been succes- 
sively overlaid in the buffer. 



End-of -Transmission and WRU 



user should edit out this substitute char- 
acter from the message. When the message 
is sent to the destination IBM or TWX ter- 
minal, the user should edit the appropriatt 
EOT character into the message. Figure 36 
provides the code representations for the 
EOTs for each terminal type. 

The user must edit out all WRU charac- 
ters appearing in messages destined for TW> 
terminals (OS QTAM does not support the WRt 
functions in outgoing messages to TWX ter- 
minals). The user should also edit out EOT 
characters appearing in messages destined 
for TWX terminals, because EOT will cause 
the terminal to disconnect from the line 
prematurely (i.e., while QTAM is preparing 
to send additional messages to the same 
terminal). To disconnect a TWX terminal 
from the line, the TWX operator sends an 
EOT from his terminal when he receives the 
CPU identification sequence from the com- 
puter. See the section entitled Management 
of Switched Lines. 



All IBM terminals employ a single end- 
of-transmission (EOT) character called a 
(cT) . TWX terminals also employ a single 
EOT character. The 8 3B3 and 115A terminals 
represent EOT by the sequence 
FIGS H LTRS. 

An EOT in a message sent from an IBM or 
TWX terminal to an 83B3 or 115A terminal is 
translated by QTAM to the two-character 
sequence FIGS H. The LTRS character is 
not sent, so the EOT sequence is not com- 
plete. The sequence is completed when QTAM 
deselects the terminal prior to polling the 
line or addressing a terminal on the line. 
When QTAM sends the EOT character that 
always begins a polling or addressing 
operation, the TCU first sends the LTRS 
character, completing the EOT sequence. 
The TCU then sends the complete EOT 
sequence FIGS H LTRS again. The EOT 
sequence thus appears on the receiving line 
twice, out this has no ill effect. 

The EOT sequence FIGS H LTRS sent from 
an 8 3B3 or 115A terminal to an IBM or TWX 
terminal appears in main storage as an 
upshift H (transmission code X'25'). The 
TCU deletes the LTRS character from the 
incoming data stream. The upshift H is 
treated as an invalid character by the QTAM 
translate table; it is translated to a sub- 
stitute character (X'3F*, in EBCDIC). The 



End-of-Messaqe, End-of-Transmission, and 
WRU for WTTA Terminals 



The World Trade Telegraph Adapter recog- 
nizes two end conditions that are set in 
the hardware at the time the control unit 
is installed. These are FIGS x and FIGS y 
LTRS„ where x and y are characters assigned 
by the user of a specific system. 

For a terminal equipped with the Auto- 
matic Answerback Unit, FIGS x must be the 
code combination No. 4 (FIGS D) sent by the 
terminal WRU key. FIGS D is referred to as 
the WRU signal. For terminals not equipped 
with the Automatic Answerback Unit, any 
other code combination can be selected. 

Note 1 : x and y must not be the same 
character. 

Note 2 : The FIGS y LTRS sequence causes a 
Read operation to end. Therefore, FIGS y 
can be sent by a terminal as data only if 
it is not followed by LTRS. 

The above termination signals can be 
used as EOM signals. Either the FIGS y 
LTRS sequence (if not yet used as an EOM 
signal) or two consecutive EOM signals can 
represent the signal. 
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Terminal Type 



| EOA Sequence | EOT Sequence 

\r t r + t t- 

| | Trans | | | Trans 

{Characters | Code j EBCDIC | Character |Code 

I | (hex) | (hex) | I (hex) 



IBM 



2260 



STX 



| 02 



02 



|eot ( (£) ) | oa 



| all othersj EOA ((g)) 1 16 | 7B |EOT ( © ) | IF | 37 J 



Non-IBM | 8 3B3 

I- 4 

J115A | Space \QH | 40 |FIGS H LTRS|1B0 51F 

|TWX | | | |EOT | 21 



|CR LF LTRS|02081F|0D2506|FIGS H LTRS | 1B0 51F| 368806] 

3688061 






WTTA 



|EOM 
I EOT 



| Note* 
| Note* 



EBCDIC! 
(hex) j 



37 



;r~1 



37 
37 



j*Note: Any character assigned by the user. 

L 



Figure 36.. EOA and EOT Characters and Sequences 



Appendix H 155 



APPENDIX I: QTAM CHECKPOINT DATA RECORD 



1 



Record Format: 



j. T T T T T T 1 

jt Next jt lst|TERM ENTRIESJQCB ENTRIES | POLL LISTSJLCB ENTRIESJDEAD LETTER] 
| Disk Loc| QCB | III I QCB ENTRY# ] 

L X X X X X X J 

L 4 X 1\ J 



Formats of Fields : 
1. Save all terminal entries (except distribution lists) 

r t 



TERM ENTRY 



| Terminal Table Entry ] 
|. .J 

i size of TERM entry + 1 J 



2. Save QCB's only if current QCB is not the same as the last QCB saved. 

| PROCESS 
|QCB ONLY 



QCB ENTRY 



r t t t + 1 

JQSIZEI QNASE | QBACK |QFAC j t CURRENTJ 
|| || JMSG HDR | 

L — 2 — J- 3 -L — 3 — J- — 3-J- 3 J 

3. Save polling list only if the list is not the same as the last polling list saved. 

r t t 1 

POLLING LIST | SIZE | STATUS j VARIABLE INFO] 

l — i_x i__x variable — J 

4. Save LCB information based on QRLM of current QCB being checkpointed.. 

r t r t t 1 

| LCBHDR | LCBTTIND ] LCBSTATE | LCBNASEG j UNIT ADDR ] 

L 3 — J 2 — -L 1 -L 3 » 2 J 



Control Record: 



r t 1 

| STATUS | Not Used | 
L X J 



Status 

00 Normal Close 

01 Abnormal Termination Area 1 Good Info 

02 Abnormal Termination Area 2 Good Info 
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APPENDIX J: RETURN CODES FOR MACRO INSTRUCTIONS USED TO MODIFY AND EXAMINE SYSTEM 



Upon return from the message processing 
routine for the macro instruction, the 
return codes shown in the following chart 



are set in the low order byte,, right- 
adjusted, in register 15. All numbers in 
the chart appear in hexadecimal notation. 



T 

R 

E 
L 
E 
A 
S 
E 
M 

+ 

X'OO* 

+ 

X' 04* 

+ 

I 

+ 

X*20" 
+ 

+ 



T 

I R 

I E 

I T 

I R 

J I 

J E 

I v 

I E 
+ 

IX'OO* 

+ 

+ 

+ 

+ 

+ 

|X*02' 
+ 

ix'to' 

+ 

jx^o* 

+ 

+ 

+ 



Normal 
Re turn 

Unopened 
DCB 

Line Not 
INTERCPTED 

Invalid Relative 
Line Number 

Invalid 
Count 

Invalid Disk 
Address 

Invalid Sequence 
Number 

Invalid Terminal 
Table Entry 

Work Area Larger 
Than Buffer 

Segments Not In 
Sequence 

Restart in 
Progress; Release 
Not Executed 






+ + 

X'01' 



4 + + + 






X'00' 



x'os* 

X* 10 • 



X'10' 






X" 20' 



X'OO* 



X'00' 

+ + 

X'01" 



+ + 

X'08 f 









X'20 






4 4 + + 



4 + + + _ 



4 

+ + 



X'20' 



X«00' 



X f 20« 



C 

o 
p 

Y 

T 

+ 

|X'00' 

+ 

4 

+ 

+ 

+ 

|X'20 f 

+ 

+ 



P 

u 

T 
+ 

X'OO* 

+ 

+ 

+ 

4 



4 

X'20' 

4 

X'10' 

4 

X^O' 



_ + 



X'02» 



S 
T 
A 
R 

P 
L 
N 

X'00' 

4 

X'Ol* 



-4 + ^ 



s 

T 

c 
p 

L 

N 

4 .j 

X'00' 

4 ^ 

X'01' 



4 

x'OS" 

4 

X'20' 

4 

4 



4 ^ 

X*08 f 

4 ^ 

4 ., 

4 ^ 

4 .J 

X'20» 

4 ., 

4 ^ 

4 ^ 
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APPENDIX K; DISK QUEUING RULES 



The data set defined for the DASD message 
queues contains one queue for each DASD 
process and DASD destination queue defined 
via the terminal table. Relative record 
locations 2 through n+1 each contain the 
first record for queues 1 through n. The 
ordinal indication of the queue is in bytes 
2^Pof~the QCB whose address is in bytes 1 
through 3 of the terminal table entry 
(TQCBADDR) . Beginning at the record speci- 
fied in bytes 2-4 of the QCB, the queue is 
chained through the data set. Rules for 
chaining are as follows: 

1. The relative record address of a seg- 
ment on disk is contained in bytes 5 
through 7 of the disk segment MSLCB. 

2. The relative record address of the 
next segment of a message is contained 
in bytes 8 through 10 of the disk seg- 
ment MSLINK. 

3. The relative record address of the 
header of the current message (if this 
is a text segment) or of the header of 
the previous message (if this is a 
header segment) is contained in bytes 
11 through 13 of the disk segment 
MSHEAD. 

4 . The relative record address of the 
header for the next message is con- 
tained in bytes 14 through 16 of a 
header segment MSDLINK. 



Relative record location 1 contains the 
first record of the dead-letter queue. 
This queue contains all messages whose 
destinations are invalid. For multiple- 
routed messages, the message will appear in 
the dead-letter queue once for each invalid 
destination. This is in addition to the 
queuing of the message in a DASD process or 
DASD destination queue for a valid 
destination. 



Messages placed in a DASD queue via mul- 
tiple destinations in the header, a distri- 
bution list„ REROUTE macro instruction, or 
an ERRMSG macro instruction follow these 
rules: 

1. The primary destination (first DASD 
queue into which message is placed) 
contains the header segment and all 
text segments. The REROUTE bit in 
MSTATUS (bit 1 in byte 12) is set to 
zero in the header prefix. 

2. All subsequent DASD queues used as 
destinations contain the header seg- 
ment only. The REROUTE bit is set to 
one in the header prefix of each of 
these messages. 

3. The header segments of these secondary 
destinations are chained to the re- 
spective text segments, which are in 
the primary queues. 
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APPENDIX L; QTAM SAMPLE PROGRAM A 



The following example is designed to pre- 
sent the basic structure of a QTAM message 
control program. (See Appendix M for a 
more complicated sample program.) The pro- 
gram is designed to receive iressages from 
two IBM 1050s and put them on the destina- 
tion queue for any or all of the following: 

• Queue for the first 1050. 

• Queue for the second 105 0. 

• Queue for the process program. (The 
message processing program is not 
included in this example.) 

The program will translate each incoming 
message segment from 1050 transmission code 
to EBCDIC, count the incoming message head- 
ers received from each terminal, route the 
message to the proper destination queue, 
and check the incoming message sequence 
number . 

Outgoing messages will be translated 
from EBCDIC to 1050 transmission code. The 
output sequence number will be inserted, 
and idle characters will be sent over the 
line when the carriage return- line feed 
character is recognized in the message 
segment. 



The format of the incoming message is: 

#NXXXXX SEQ TERMX YYYY ,.. .....C 

where: 

# = EOA 

N = new line character 

XXXXX = name of terminal originating 
message 

SEQ = input sequence number 

TERMX = name of destination 

YYYY = output sequence number 

, . . ,....= message sent 

C = carriage return character 

Each message must be preceded by a new line 
character. The following statements are 
not meant to be card images, but aides to 
the user in organizing his message control 
program. 



■T T 

| Operation | Operand 



"T 

j Remarks 



Name 



j. 

| EXAMPLE 


-+ 

A j CSECT 

|SAVE 
|BALR 
| USING 


-+ 

| (14,12) 
1 11„ 
|*,11 










_ + 

| INLINE 
]CODE 




|ST 


|13,SAVEAREA+4 










JLA 


| 13, SAVE AREA 










jB 


|OPEN 












J. 


-+ 

j TERMTBL 


-+ 

| PRCSS 










_ + 

] Terminal table definition. 

| PRCSS is name of last entry in table. 


|CNTR 


| OPTION 


|H 










J Optional field in terminal table. 


| PLIMIT 


| OPTION 


|XL1 










j Optional field in terminal table. 


| TERM1 


|TERM 


|T,LINE1 


,1 


,E213E215, 


(0, 


1) 


j 1050 destination entry. 


|TERM2 


|TERM 


|T,LINE2 


rl 


,E213E215, 


(0, 


1) 


j 1050 destination entry. 


| PRCSS 


| PROCESS 












j Process Program destination entry. 



L ± JL X ; ■ J 

(Part 1 of 3) 
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r t t 

| Name | Operation | Operand 
| + _ + 



•T 

] Remarks 
-+ 



P0LLINE1 
P0LLINE2 



BUFFER 

POLL 

POLL 



4„92,5,BRB=4 

(TERM1) 

(TERM2) 



4(92 byte) buffers. 
Polling list for LINE1, 
Polling list for LINE2. 



LINE1 



DCB 



LINE2 



DCB 



DDNAME=LINElDD, 

DSORG=CX, 

MACRF=(G,P), 

CPOLL= ( POLLIN El ) , 

BUFRQ=2,INTVL=0, 

CPRI=S, 

CLPS=LPS 

DDNAME=LINE2DD, 

DSORG=CX # 

MACRF=(G,,P) f 

CPOLL= ( POLLINE2 ) , 

BUFRQ=2 r 

INTVL=0,CPRI=S, 

CLPS=LPS 



DCB for first line. 



DCB for second line.. 



DISK 



DCB 



DDNAME=DISKDD, 

DSORG=CQ,, 

MACRF=(G W P) 



DCB for direct access message queue. 



ECB 



SAVEAREA 



DC 



DC 



X'40000000 



lSF'O' 



ECB with complete bit set on. Used only 
for WAITR. 

User's save area. 



OPEN 



OPEN 

WAITR 

ENDREADY 
CLOSE 
L 
RETURN 



(DISK,, (INOUT), 
LINE1,, (INOUT),, 
LINE2,, (INOUT)) 

ECB=ECB 



(LINEL, ,LINE2» I# DISK) 

13 f SAVEAREA+4 

(14,12) 



Note: Disk data set must be first one 



opened. 



Causes scheduler to be associated with 
the next lower partition. WAITR is not 
needed for release 16 or 17 systems. 



— + 



LPS 



LPSTART 

RCVSEG 

TRANS 

RCVHDR 

SKIP 

COUNTER 

SOURCE 



5 if TERM=(1050) 

Receive Portion of LPS. 

RCVF105 
CNTR 



Leave 5 spaces in buffer for header 
expansion for SEQOUT Field. 



Translate from 1050 code to EBCDIC. 

Skip to NL character. 

Count headers for each terminal. 



(Part 2 of 3) 
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I Name j Ope rati on j Operand 

y + + 



] Remarks 
■+ 



SEQIN 

ROUTE 
ENDRCV 
EOBLC 
ERRMSG 

POSTRCV 

SENDHDR 

SEQOUT 

SENDSEG 

TRANS 

PAUSE 

END SEND 

EOBLC 

POSTSEND 



X , 0200' f =CL5'TERMl* f 
=C. INVALID SOURCE' 



Send Portion of LPS* 



SEND105 
X'SB'^OX'SE* 



Check incoming sequence number for 
validity. 



Check for correct reception ox message. 



Insert output sequence number. 

Translate from EBCDIC to 1050 code. 
Insert 20 idle characters. 

Check for correct message transmission. 



| END | EXAMPLE 
.X J. 



(Part 3 of 3) 
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APPENDIX M: QTAM SAMPLE PROGRAM B 



The following example is an OS QTAM message 
control program. The purpose of the pro- 
gram is to switch messages between a non- 
switched 1050, a switched 1050 and an 83B3. 
In addition, a message can be sent to a 



message processing program for closedown. 
(See IBM System 360 OS QTAM Message Pro- 
cessing Program Services Appendix D for the 
related MPP.) 



* * 

* PROGRAM: OS QTAM MESSAGE SWITCHING * 

* TERMINALS SUPPORTED: * 

* SWITCHED 1050 * 

* NONSWITCHED 1050 * 

* NONSWITCHED 83B3 * 

* FORMAT OF TERMINAL INPUT: * 

* CR (FIGS H LTRS FOR 83B3) * 

* SOURCE TERMINAL <Z PRECEDES ATL IN 83B3 FOR SKIP MACRO) * 

* SPACE * 

* MESSAGE SEQUENCE NUMBER (3 DIGITS) * 

* SPACE * 

* DESTINATION TERMINAL(S) * 

* SPACE * 

* SLASH * 

* SPACE * 

* MESSAGE * 

* EOB (AT THE END OF EACH BLOCK) * 

* EOT (AT THE END OF EACH MESSAGE) * 

* EE * 

* EXAMPLE: RTP 001 ATL NYC / THIS IS THE MESSAGE 00 * 

* BT * 

* OUTPUT OF MESSAGE ORIGINATED AT A 1050 * 

* SOURCE TERMINAL * 

* SPACE * 

* MESSAGE SEQUENCE NUMBER * 

* SPACE * 

* DESTINATION TERMINAL(S) * 

* SPACE * 

* SLASH * 

* SPACE * 

* DATE (YEAR AND DAY OF YEAR) * 

* SPACE * 

* TIME (HOUR, MINUTE AND SECOND) * 

* SPACE * 

* OUTPUT MESSAGE SEQUENCE NUMBER (ONLY IF 1050 TO 1050) * 

* SPACE * 

* MESSAGE * 

* EXAMPLE: RTP 001 ATL NYC / 68.065 10.16.33 001 THIS IS THE MESSAGE * 

* * 

* OUTPUT OF MESSAGE ORIGINATED AT A 83B3 * 

* SOURCE TERMINAL * 

* SPACE * 

* MESSAGE SEQUENCE NUMBER * 

* SPACE * 

* DESTINATION(S) * 

* SPACE * 

* SLASH * 

* SPACE * 

* OUTPUT MESSAGE SEQUENCE NUMBER (ONLY IF 83B3 TO 1050) * 

* SPACE * 

* MESSAGE * 

* EXAMPLE: RTP 001 ATL NYC * THIS IS THE MESSAGE * 



OSQTAM CSECT 



*###*######*#####*##**###* 



SAVE (14,12) ttWILLI 

BALR 12,0 

USING *,12 

ST 13.SAVEAREA+4 

LA 13,SAVEAREA 

8 OPEN 
ECB DC X' 40000000' 
SAVEAREA DC 18F'0" 

OPEN OPEN (DISKDCB,( INOUT ) .CKPNTDCB, ( INOUT ) ,NYCDCB, ( INOUT ) , 
ATLDCB,(INOUT),RTPDCB,( INOUT) ) 

WAITR ECB=ECB 

ENDREADY 

CLOSE (NYCDCB,,ATLDCB,,RTPDCB,,CKPNTDCB,,DISKDCB) 

L 13,SAVEAREA+4 

RETURN (14,12) 



Used only by WAITR 



* Disk data set must be opened first and checkpoint data set 
must be second. 



This instruction is needed only for systems prior to 
release 15. 



Disk data set must be closed last and checkpoint data set 
must be next to last. 
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*********************************************************************** 
******** TERMINAL LIST ************************************************ 

*********************************************************************** 

TERMTBL E0J,CPINTV=2 

C0UNT1 OPTION H 

COUNT2 OPTION H 

POLLMT OPTION FL1 

RTP TERM TtRTPDCB,l,E213E215, (0,0,9) 

NYC TERM T,NYCDCB,1,E213,(0,0),CALL=5880 

ATL TERM T,ATLOCB, 1 , 181 31807 

ALL OLIST (RTP, NYC, ATL) 

EOJ PROCESS 

*********************************************************************** 
******** BUFFER POOL FOR INPUT AND OUTPUT ***************************** 
*********************************************************************** 

BUFFER 20,120,8 

*********************************************************************** 
******* POLLING LISTS ************************************************* 
*********************************************************************** 

RTPPOLL POLL (RTP) 

NYCPOLL POLL E215 

ATLPOLL POLL (ATL) 

*********************************************************************** 
******** OCB'S.ECB AND SAVE AREA ************************************** 
*********************************************************************** 



RTPDCB DCB 



DSORG=CX, 

MACRF=(G,P), 

DDNAME=RTPDD, 

CPOLL=(RTPPOLL), 

BUFRQ=5, 

CPRI=E, 

CLPS=LPS1050 



EOJ is last item in term table and checkpoint records will 

be taken every 30 seconds (2x15). 
Storage for counting incoming messages from 1050. 

Storage for counting outgoing messages for 1050. 

Storage for polling limit for NS 1050. 



Only addressing characters defined -for SW 1050. 



Destination ALL sends the message to all terminals. 

EOJ refers to a DD card in the MPP JCL (//EOJ DD DUMMY) , 



20 buffers of 120 bytes each and 8 CCWs that QTAM generates 
for the PAUSE macro. 



Polling list for NS 1050. 
Polling characters for SW 1050. 
Polling list for 83B3. 



Data set organization is that of a communications line group. 

A queued access method is used to access the line group. 

Name of DD card that identifies the line. 

Identifies polling list for this line. 

Buffers requested for transmission of data from terminal to 

computer . 
Receiving and sending have equal priority. 

Identifies the line procedure specifications for this line. 



NYCDCB DCB 



DS0RG=CX, 

MACRF=(G,P), 

DDNAME=NYCDD, 

CP0LL=(NYCP0LL), 

BUFRQ=5, 

CPRI=E, 

CLPS=LPS1050 



DCB DSORG=CX, 

MACRF=(G,P), 

DDNAME=ATLD0, 

CP0LL=(ATLP0LL), 

BUFRQ=5, 

CPRI=E, 

CLPS=LPS83B3 



CKPNTDCB DCB DS0RG=CQ, 

MACRF=(G,P), 
DDNAME=TCHKPNT 



* Data set organization is that of the direct access message 

queue or the checkpoint for the MCP. 

* Records are to be accessed with GET and PUT macro instructions. 

Name of DD card that describes the checkpoint data set. 



DISKDCB DCB DS0RG=C0, 

MACRF=(G,P), 
DDNAME*DISKDD 
DC XL50'FF< 



* Data set organization is that of the direct access message 

queue or the checkpoint for the MCP. 

* Records are to be accessed with GET and PUT macro instructions. 

Name of DD card that describes the message queue data set. 
Needed only for systems prior to release 15. 
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ft********************************************************************** 
******** LIME PROCEDURE SPECIFICATIONS FOR SW 1050 AND NS 1050 ******** 
*********************************************************************** 

LPS1050 LPSTART 21 ,TERM=( 1050 ) 

RCVSEG 

TRANS RCVF1050 



21 bytes reserved in msg hdr=9 for dates tamp + 7 for 
timestamp + 4 for SEQOOT + 1 for the MVI instruction. 



Translates 1050 code to EBCDIC. 



RCVHDR 
SKIP X'15« 
SOURCE 3 
SEOIN 3 
ROUTE 3 
EOA C'/' 
0ATESTMP 
TIMESTMP 9 
COUNTER C0UNT1 



Move SCAN pointer to the CR character in the buffer. 
Checks to see if the source code is valid. 
Checks to see if the input sequence number is valid. 
Checks to see if the destination code is valid. 
/ will identify the end of the destination codes. 
Inserts date into header after /. 
Inserts time into header after date. 
Counts incoming messages from the 1050. 



ENDRCV 

POLLIMIT P0LLMT 

CANCELM X'B600' 

EOBLC 

ERRMSG X'0200' .SOURCE, =C ' INVALID SOURCE' 

ERRMSG X'2000' .SOURCE, =C'SEQUENCE NUMBER TOO HIGH. USE$ 

ERRMSG X'1000' .SOURCE, =C'SEQUENCE NUMBER TOO LOW. USES 

ERRMSG X'8000' .SOURCE, =C*INVALID DESTINATION' 



The poll limit is found at the location POLLMT. 

Cancel the message if any of the following bits are on in 

the error halfword: 1011011000000000. 
Sends a positive or negative acknowledgment when EOB is 

received. 
0200,2000,1000,8000 indicate error halfword bits. 
SOURCE: Error msg is sent to terminal originating the msg 

in error. 
$ causes the correct input sequence number to be included 

in the error msg. 



SENDHDR 

COUNTER C0UNT2 

SEQOUT 4 

MVI 32<6),X'15' 



Counts outgoing messages to the 1050. 

Puts the correct sequence out number in all messages going 

to the 1050. 
Insures that a NL character is the first character in the 

buffer. 



SENDSEG 

TRANS SEND1050 

PAUSE X'5B',20X'5E' 



Translates EBCDIC code to 1050 code. 



Sends 20 idle characters (5E) after a NL character (5B) is 
transmitted. 



ENDSEND 

EOBLC 

ERRMSG X ' 0080' .SOURCE, =C ' OUT PUT TRANSMISSION ERROR' 



Performs an LRC and returns a positive or negative response. 
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*********************************************************************** 
******** LINE PROCEDURE SPECIFICATIONS FOR 83B3 *********************** 
*********************************************************************** 

LPS83B3 LPSTART 1 ,TERM= ( 83B3 ) 

RCVSEG 

TRANS RCVET1 

BREAKOFF 120 



Causes the breakoff error bit to be posted if a message over 
120 characters long is received or if a buffer is filled 
with the same character. 



RCVHDR 
POLLIMIT 3 
SKIP X'E9' 
SOURCE 3 
SEQIN 3 
ROUTE 3 
EOA C'/« 



Move SCAN pointer to the Z character in the buffer. 



ENDRCV 

CANCELM X'B600' 

ERRMSG X'0200' .SOURCE, =C * INVALID SOURCE' 

ERRMSG X'2000', SOURCE, =C • SEQUENCE NUMBER TOO HIGH. USES 

ERRMSG X'1000", SOURCE, =C ' SEQUENCE NUMBER TOO LOW. USES 

ERRMSG X' 8000' .SOURCE, =C ' INVALID DESTINATION' 

ERRMSG X'0020', SOURCE, =C • MESSAGE TOO LONG' 



The two spaces at the beginning of the message plus the one 

spaee reserved in LPSTART are needed for the EOA characters. 



POSTRCV 
SENDHDR 
MVC 32(3,6),=X'0D2506' 



Inserts the 83B3 EOA characters. 



SENDSEG 
TRANS SENDT1 



ENDSEND 

ERRMSG X'40FC .SOURCE, =C .TRANSMISSION ERROR' 



The period ( . ) causes the header to be inserted into the buffer 
preceding the text. 
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APPENDIX N; ON-LINE TERMINAL TESTING 



The on-line terminal test facility provides 
tests that can be used by the terminal 
operator as a startup procedure and by the 
IBM customer engineer for terminal checkout 
and diagnosis of terminal failure. 

The tests operate on-line with the 
user's problem program and in no way affect 
user operation except for the line time 
required by the terminal tests to perform 
their function on the selected line. 

Tests requested from a terminal can be 
returned to that terminal, to any other 
terminal on the same line, or to any other 
terminal in the system. The tests are: 
message switching, comparison of incoming 
data to a stored pattern in core storage, 
all- characters messages sent to specified 
terminals, and test patterns for diagnosis 
of failures in the SELECTRIC ^ typing ele- 



ment of the terminal. 



<8> 



Requests for the various tests are 
entered from a remote terminal and are 
identified by a test activation code of 
99999. The individual tests and terminal 
addresses are selected by secondary activa- 
tion codes. 

Tests are not provided for Teletype 
terminals. 



FORMAT OF TEST REQUEST MESSAGES 



All fields of the test request message are 
consecutive: that is,, they are not 
separated by blanks. 

The total length of the test request 
message should not exceed the size of a 
buffer as specified in the BUFFER macro 
instruction. Data not included in this 
first buffer will not be processed. 



The format of the test control message 



is: 



99999 format- integer test- integer type- 
integer taddr-char (s) ] [unit-char ( s) ] 
ttext-chars] end-char 



where : 



99999 



is the primary action code used to 
identify this message to the system as 
a test request message. This field 
must always appear, exactly as shown,, 
in every test request message,. 



format 

defines the test header format; it is 
either or 1. Format uses actual 
line addresses and can be used to 
address any terminal on the same line. 
Format 1 uses symbolic addresses and 
can be used to address any terminal 
within the system. 



test 



type 



addr 



specifies the test to be executed. It 
is always one integer (1 through 9 
described in the section Types of 
Tests Available) . 



specifies the type of terminal for 
which the test is being requested. 
Type codes that may be used are shown 
in the following table: 



| Terminal Type 
h 



JType Code 



IBM 1030 

IBM 1050 

IBM 10 60 

IBM 2740 

IBM 1030 - Badge reader 
or Manual Entry 

IBM 22 60 




Exception : Type code 5 is used only 
with format 0. It defines the type of 
terminal requesting the test (as well 
as the type of terminal for which the 
test is being requested). 



is the address of (a) the terminal to 
which a test iressage is to be sent 
(tests 1,, 6, and 8); (b) the terminal 
at which a device to be tested mechan- 
ically is located (tests 2, 3., 4, and 
7) ; or (c) the terminal to which a 
response message from the terminal- 
test facility is sent (test 5), (Test 
9 does not utilize the address field. ) 

Note: For the IBM 1050* 1060, and 
2 260-2848, two addressing characters 
are specified in the TERM macro 
instruction. For these devices, the 
first of the two addressing characters 
is the actual address of the terminal, 
and is therefore the character to be 
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specified in the addr field. The 
second of the two addressing charac- 
ters specifies the particular device 
at the terminal, and is specified in 
the unit field discussed below. 



When used with format 0, this is a 
one- or two-character field depending 
on the type of device from which the 
test request message is being entered. 
It is a one-character field for the 
IBM 1030 card reader, IBM 1050 
devices, and IBM 2740 devices, and is 
the addressing character for the 
selected terminal- Only one character 
is necessary because these devices are 
capable of transmitting the actual 
alphabetic terminal address character. 



For the IBM 1030 badge reader or manu- 
al entry, IBM 1060 devices, and IBM 
2260 devices, this field must consist 
of two characters. The address is 
selected by transmitting a predefined 
code as follows: 



Terminal Cede 
Address Entered 



1. IBM 1060: 

Terminal 
Address 

A 

B 

C 



Code 
Entered 

01 

02 

03 



26 



IBM 1030 badge reader or manual 
entry: 



Terminal 
Address 

B 

C 

D 



Code 
Entered 

02 

03 

04 



26 



Note : If 10 is entered as the 
addr field, the message will be 
considered an invalid request, 
because the corresponding address 
(J) is not a legal IBM 1030 
address . 

3. IBM 2260 devices: the addr field 
is used to select the IBM 2848 
display control unit. The 
address of a display control unit 
can be any ASCII noncontrol char- 
acter; therefore there are 96 
possible display control unit 
addresses. 



0100000 
0100001 
0100010 



1111111 



01 
02 
03 



96 



unit 



Note : The predefined code appli- 
cable to a particular display 
control unit can be determined 
from a display station by utiliz- 
ing the Request Address test 
(test 9). 

When used with header format 1, 
this field is variable in length 
(from one to nine characters). 
The first character is a digit 
defining the number of following 
characters that constitute the 
symbolic address name. This sym- 
bolic address name defines a ter- 
minal in the terminal table. 

Examples: 

a. 4CHII (four- character symbol- 
ic name) 

b. 7CHICAGO (seven-character 
symbolic name) 

c. (a zero indicates that the 
test is to be returned to the 
requesting terminal) 

Note that terminal CHI I could 
request a test for itself by 
using either example a or c. 



specifies the particular unit at the 
terminal specified in the addr field. 
This field is used only when the for- 
mat is specified. When using format 
1, both the terminal and the unit at 
the terminal are defined by the sym- 
bolic name in the addr field. 

For IBM 1050 and IBM 1060 devices, one 
character is specified. The appropri- 
ate code can be determined from the 
publication describing the type of 
terminal being addressed. 

Note : this field is not applicable to 
IBM 1030 and IBM 2740 devices; there- 
fore text can start in this position. 

For IBM 2 848 devices, two characters 
are specified. IBM 2260 display sta- 
tions are selected by transmitting a 
predefined code. The device selection 
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character can be any of 2 5 ASCII non- 
control characters . 



text 



end 



Device Selection 
Character in ASCII 

1000000 
1000001 
1000010 



1011000 



Code 
Entered 

01 
02 
03 



25 



Note; The predefined code applicable 
to a particular display station can be 
determined from a display station by 
utilizing the Request Address test 
(test 9). 



is the text of the message sent as a 
part of the terminal test. Text is 
included only when using the Message 
Switching test (test 1) , Stored Com- 
pare test (test 5), or Write Line 
Address test (test 8). 



is the end character for the device 
from which the test request message is 
being transmitted. 



Device 



End Character 



IBiM 1030 




EOB 


IBM 1050 




EOT 


IBM 1060 




EOB 


IBM 2740 




EOT 


IBM 2260 




ETX 


Note: The 


header 


as transm: 



an IBM 1060 device is entered by uti- 
lizing the data and transaction keys. 
The EOB character is entered by de- 
pressing the Teller A or Teller B key. 



TYPES OF TESTS AVAILABLE 



A total of nine tests are provided for IBM 
1030, 1050, 1060, 2740, and 2260 devices,. 
The integer associated with each test 
description is the code to be entered in 
the test field to select that test for use. 

1 Message Switching . This test will 

receive a message from the requesting 
terminal and return it to the same 
terminal or to any other terminal as 
specified in the addr field- 



Note: the nuirber of characters that 
can be switched is directly dependent 
on the buffer length that the user 
specifies in the BUFFER macro instruc- 
tion. The total length of the test 
request message must not exceed this 
length» Data in subsequent buffers 
for this message will not be switched. 

Tilt . The tilt test is sent to the 
terminal specified in the addr field. 
This test is designed to check the 
SELECTRIC typing element. 

Rotate . The rotate test is sent to 
the terminal specified in the addr 
field. This test is designed to check 
the SELECTRIC typing element. 



Twist. 



The twist test is sent to the 



terminal specified in the addr field. 
This test is designed to check the 
SELECTRIC typing element. 

Note: The inability of the SELECTRIC 
typing element tc perform correctly 
the tilt, rotate, and twist tests is 
normally detected by observing par- 
tially printed characters within the 
pattern, printed during the test. 

Stored Compare . The text transmitted 
from the requesting terminal is com- 
pared with a stored message in the 
CPU. The message in storage is com- 
patible with the transmitting capabil- 
ities of the terminal (s) involved. 
The compare message sent from the ter- 
minal consists of the numbers 
through 9 followed by the alphabet (A 
through Z) . The alphabet is entered 
in lower case from an IBM 1050 or an 
IBM 2740. 



Exceptions: 



1. When transmitting from an IBM 
2740 terminal with station con- 
trol a space character must pre- 
cede the comparison data; when 
transmitting from an IBM 2740 
terminal without station control, 
two space characters must precede 
the comparison data. 



The Stored Compare test for an 
IBM 1060 is requested by entering 
the following message: 



999996534210 



TELLER A 



TELLER B 



Comparison is then made to this 
message. Response to this 
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request is printed only at the requesting 
terminal. 

The number of characters that can 
be compared is directly dependent 
upon the data length of the buf- 
fer that the user specifies in 
the BUFFER macro instruction. 
The total length of the test 
request message must not exceed 
this length. 

If the comparison to the stored 
message is valid,, the following 
message is sent to the terminal 
specified in the addr field: 

CMP VLD-n 

where n is the last character 
against which a comparison could 
be made. If the data length of 
the buffer as specified in the 
BUFFER macro instruction is not 
great enough to hold all of the 
message transmitted, the message 
is truncated after one buffer is 
filled and comparison is made 
only to the contents of that buf- 
fer. So long as the text con- 
tents of that buffer is valid, 
the comparison is considered 
valid. However, if the buffer 
length is so limited that no 
characters can be compared, n is 
a slash (/). 

Exception; The message sent to 
an IBM 1060 after a valid com- 
parison is: 

CMP VLD 

If the comparison to the stored 
message is invalid, the data 
received is message switched to 
the terminal specified in the 
addr field. 



24 For IBM 1050 and 2740: numbers 
0-9, alphabet a-z (lowercase) , 
and alphabet A-Z (uppercase). 

7. Carriage Mechanism Analyzer . A 

defined message in storage is used to 
exercise the terminal specified in 
order to analyze the capability of the 
typewriter carriage mechanism to per- 
form within defined specifications. 
This test is not applicable to an IBM 
1053 printer attached to a remote 2848 
control unit. 

8 Write Line Address (2260 only) . This 
is a line selectivity test that uses 
the first two characters after the 
unit field (format 0) or the addr 
field (format 1) as a new line code. 
These characters can be followed by 
data that is to be switched to the 
terminal and written on the line spec- 
ified on the display station screen. 
The following characters are used to 
select the line on the display station 
screen: 



Characters 



01 



09 
10 
11 
12 



Line Number 



#1 



#9 
#10 
#11 
#12 



Request Address (2260 only) . The addr 
and unit fields are not used in this 
test. ETX can be sent immediately 
after the type field. The message 
returned to the requesting display 
station is in the following format: 

DC + DV dcaddr dvaddr 

where : 



Note: The Stored Compare test is 
not applicable to the IBM 1030 
badge reader or manual entry. 
This test is also not valid for a 
1060 terminal on a line with Auto 
Poll. 



All Characters . This is a standard 
all characters test for customer 
engineer terminal checkout and for a 
"good morning" message for the user. 
Special characters are not used in 
this test. Characters received at the 
terminal are: 

1. For IBM 1030, 1060, and 2848 

(2260 and 1053): numbers 0-9 and 
alphabet A-Z.. 



dcaddr 

is the predefined code necessary 
to select this display control 
unit (two bytes) . 

dvaddr 

is the predefined code necessary 
to select this display station 
(two bytes) . 



TERMINAL TEST RULES 



The data length of the buffer as spec- 
ified in the BUFFER macro instruction 
must be long enough to contain all of 
the test request header (that is, all 
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of the test request message before the 6. 
text field) . 



To request a test from an IBM 1030 

badge reader,, the badge reader must be 7. 

wired to read out the entire ten 

columns of the badge. (Refer to the 

appropriate publication on IBM 10 30 8. 

devices. ) 

The transaction code received from IBM 

1030 devices is not included as part 

of the test request. 9. 

When using header format 0, all IBM 
1030 tests require an IBM 103 3 printer 
on the same line as the requesting 
terminal. The printer is specified in 10. 
the addr field. 

The terminal test will not test the 
IBM 1035 badge readers or IBM 1030 
badge readers in a 1035 environment. 



When switching messages from one ter- 
minal to another, the sending terminal 
must conform to the character set of 
the receiving terminal. 

A maximum of 63 characters can be 
switched to an IBM 1033 printer. 

To return a test to the requesting 
terminal on a dial line,, format must 
be used and EOT must be sent within 
the first buffer. 

On an IBM 2740 basic terminal or ter- 
minal on a line with Auto Poll, format 
1 must not be used with a zero in the 
addr field. 

If the terminal requesting the online 
terminal test is a nonswitched termi- 
nal polled under control of the Auto 
Poll feature, and the message format 
is 0, then the EOT character must be 
in the first buffer. 
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APPENDIX O: CPU USAGE METER CONTROL 



During periods of low message traffic the 
user of Teleprocessing often desires to 
shut off his meter for a period of time and 
then resume operation. The QTAM user can 
do so by using the interval timer- In 
order to use this capability, the interval 
timer feature must be present and all 
necessary requirements for the feature must 
be met. 



lines overlap, the meter will be shut off. 
Instructions to change the INTVL field can 
be inserted into the LPS section of the 
message control program as follows: 



USING IHADCB, 5 



LPS LPSTART TERM=(1050) 



Set up address- 
ability for DCB 
DSECT 



IBM System/3 60 Operating System Supervi- 
sor and Data Management Services , Form C28- 
6646, should be used to obtain necessary 
information about the interval timer and 
the use of the STIMER macro instruction. 
When there is no activity in the system, 
the STIMER macro instruction may be issued. 
This will cause the meter to be shut off 
for the specified period of time. A mes- 
sage processing program may be entered to: 

(1) stop all nonswitched and noncontention 
line groups to ensure there is no activity, 

(2) set the interval of time delay, and (3) 
start all nonswitched and noncontention 
line groups when the time has elapsed. 

The following example will cause the 
system to wait, with the meter off, for 
five minutes. 



LA 



MVI 



MSGTYPE CM' A message type f 

of "M" indicate 
that the inter- 
val is to be 
changed. 

5„DCB1 Set base address 
for first DCB. 

DCBINTVL^'IO' Move in desired 
interval of 
time delay. 

Change interval for each DCB. 

Execute follow- 
ing code for 
all other 
messages. 

ENDRCV 



MSGTYPE 



STOPLN TERM1,ALL (one STOPLN issued 

for each line group) 

STIMER WAIT„DINTVL=TIME 

STARTLN TERM1,ALL (one STARTLN issued 
for each line group) 



TIME DC 



CL8(00050000) 



DCBD 



DSORG=(QX) 



QTAM DSECT for 
DCB. 



In this example a "M" type of message is 
entered when the interval of time is to be 
changed. The code between the MSGTYPE 
macros changes the interval specified in 
the DCB. This will subsequently change the 
delay at the end of a polling list. All 
other messages will not execute this code. 



An alternate method for nonswitched or 
noncontention lines not employing the Auto 
Poll feature is to change the INTVL field 
of the DCB. When the intervals of the 



Note : The user must determine when his 
message traffic is slew enough to use this 
method and how to inccrporate the message 
processing program at the proper times. It 
is not necessary to employ either method 
for dial or contention lines. 
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GLOSSARY 



addressing : a procedure in which the com- 
puter transmits identifying characters to a 
terminal preparatory to sending a message 
to that terminal. 



addressing characters; a set of characters 
peculiar to a terminal and the addressing 
operation; response to the transmission of 
these characters indicates whether or not 
the terminal can receive a message. 

answering; a procedure by which a called 
party completes a connection (for switched 
lines) . 

buffer; a storage device or area used to 
compensate for a difference in the rate of 
flow of information, or the time of occur- 
rence of events. Buffers consist of main 
storage areas; size of the areas is desig- 
nated by the user. 

calling; a procedure by which a first 
party attempts to establish a connection 
with a second party through a central 
exchange. Also, dialing. 

chain; the part of a queue consisting of 
an ordered arrangement of items. The items 
are related to each other by links. One of 
more chains may exist in each queue. 

closed routine (or subroutine) ; a routine 
or subroutine that is not inserted as a 
block of instructions within a main routine 
but is entered by basic linkage from the 
main routine. 

communication line group; a group of lines 
with similar characteristics (such as asso- 
ciation with the same type of terminal 
device) . 

component; a point in a communications 
network at which data can enter or leave; 
an input/output device. A component is 
always attached to a terminal control unit. 



data collection; a telecommunications ap- 
plication in which data from several loca- 
tions is accumulated at one location before 
processing. 



data control block; an area of main 
storage that serves as a logical connector 
between the user's problem program and a 
data set. The data control block can also 
be used to provide control information for 
any transfer of data. Abbreviated "DCB". 



destination code; the name of a terminal 
or processing program to which a message is 
directed. 

destination queues, DASD; a group of 
queues in which the queue control block for 
each queue resides in main storage,, and the 
message segment chain for each queue 
resides on a direct access storage device. 

dead- letter queue; a queue containing mes- 
sages that could not be placed in the 
appropriate destination or process queue, 
The dead-letter queue begins in relative 
record address 1 on the direct access 
storage device used. 

delimiter macro instructions; LPS macro 
instructions that group functional macros 
into various coding subgroups. 

direct access queues; a group of queues, 
or, more specifically, message segment 
chains of queues „ residing on a direct 
access storage device. The group can 
include destination and process queues. 

distribution list entry; a terminal table 
entry containing information on a group of 
terminals, each of which is to successively 
receive any message directed to the group. 
The information in the entry includes rela- 
tive addresses that locate the single ter- 
minal entries for each terminal in the 
group. 

end-of- address character (machine) ; Con- 
trol character (s) transmitted indicating 
the end of non-message-data characters (for 
example, addressing characters). Abbre- 
viated, EOA. 

end-of- address character (program) ; a QTAM 
character that must be placed in a message 
if the system is to accommodate routing of 
that message to several destinations; the 
character must immediately follow the last 
destination code in the message header. 
Abbreviated,, EOA. 

exchange,, common-carrier; the location of 
a common carrier's communication equipment 
for interconnecting subscribers' lines. 

functional macro instructions; LPS macro 
instructions that operate on message seg- 
ments and perform functions such as message 
editing, checking validity of codes used in 
the header, routing messages to specified 
destinations, maintaining logs of messages, 
and checking for errors in transmission or 
spe ci f i cat ion . 
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group code entry: a terminal table entry 
containing information on a prespecified 
group of terminals with the group code fea- 
ture; this feature facilitates simultaneous 
transmission of a message to all members of 
the group through the specification of a 
single set of unique address characters. 



header: a part of the first segment of a 
message containing information necessary 
for directing the message to its destina- 
tion, and other control information. 

line control block (LCB) : an area of main 
storage containing control data for opera- 
tions on a line. The LCB can be divided 
into several groups of fields; most of 
these groups can be identified as general- 
ized control blocks. QTAM maintains an LCB 
for each line in the system. 

Line Procedure Specifications: a sequence 
of user-selected macro instructions that: 

1. Specifies the manner in which control 
information in the message header is 
to be examined and processed; and 

2. Specifies other functions (such as 
translating) to be performed. 

Abbreviated, LPS. 

log: a collection of messages that pro- 
vides a history of message traffic . 

logging: the process of recording messages 
on a storage medium for purposes of main- 
taining a history of message traffic. 

LPS control routine: a QTAM routine that: 

1. Performs initialization functions; and 

2. Obtains the address of the LPS line 
group routine to be used for process- 
ing a particular message segment. 

LPS line group routine: a user-defined 
routine comprised of subroutines necessary 
to prepare a message segment for process- 
ing, and examine and process the control 
information in the message segment. The 
functions performed are based on the user- 
selected macro instructions that determine 
the configuration of each line group rou- 
tine. Each line in the system must have an 
LPS to handle messages from terminals on 
lines in that line group. However, more 
than one line group may use the same LPS if 
they all require identical message control 
procedures. 

message : a combination of letters* digits,, 
and symbols whose termination point is 
marked by an end-of -transmission (EOT) 
character. 



message data: transmitted characters that 
are recorded as part cf a message. A mes- 
sage data area is the area in a buffer that 
receives message data. In QTAM, a message 
data area begins with either the thirty- 
third byte of a buffer (if the message data 
includes a message header) , or with the 
twenty-third byte of the buffer (if the 
message data consists of text only) . 



message segment: that portion of a message 
that fits in the message data area of a 
buffer. 

message switching: a telecommunications 
application in which a message is received 
at a central location, stored on a direct 
access device until the proper outgoing 
line is available, and then transmitted to 
the appropriate destination. 

polling : a flexible, systematic, centrally 
controlled method of permitting terminals 
on a multiterminal line to transmit without 
contending for the line. The computer con- 
tacts terminals according to the order 
specified by the user; each terminal con- 
tacted is invited to send messages. 

polling characters: a set of characters 
peculiar to a terminal and the polling 
operation; response tc these characters 
indicates to the computer whether or not 
the terminal has a message to send. 

polling list: a list containing control 
information and naires of entries in the 
terminal table for a single line; the order 
in which the names are specified determines 
the order in which the terminals are 
polled. 

polling pass: a complete cycle through a 
polling list. 

process program entry: a terminal table 
entry containing information on a process- 
ing program as the destination for a 
message. 

process queue, DASD: a queue in which the 
queue control block resides in main 
storage,, and the message segment chain 
resides on a direct access storage device. 

processing collected data: an application 
in which the data accumulated through a 
data collection application is processed. 

processing inquiries: a telecommunications 
application involving receipt of a message 
from a remote terminal* processing of the 
message, generation of a response message, 
and transmission of the response message to 
the originating terminal. 

queue : an item system consisting of: 
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1. A queue control block. 

2. One or more ordered arrangements of 
items (chains) . 

queue control block: an area in main 
storage containing control data for a 
queue. Abbreviated, QCB. 

relative line number: a number assigned by 
the user to a communications line at system 
generation. 

resource: any facility of the computing 
system or operating system required by a 
job and including main storage, input/ 
output devices, the central processing 
unit, data sets, and control and processing 
prog rams . 

single terminal entry: a terminal table 
entry containing information on a single 
terminal. 

telecommunications : any transmission or 
reception of signals, writing, sounds, or 
intelligence of any nature, by wire, radio, 
visual methods, or electromagnetic systems. 
Often used interchangeably with 
"communication. " 

Teleprinter: a trade name used by Western 
Union to refer to its telegraph terminal 
equipment. 

Teletype: a trademark of the Teletype 
Corporation. A system used for transmit- 
ting messages to remote points; the system 



employs keyboard or paper tape sending and 
printed receiving. 



Teletypewriter : a trade name used by AT&T 
to refer to its telegraph terminal 
equipment. 

Teletypewriter Exchange Service (TWX) : a 
switched network providing the means for 
interconnecting AT&T subscribers. 

terminal : a point in a system at which 
data can enter, leave, or enter and leave- 
A terminal can also be a control unit to 
which one or more input/output devices can 
be attached (see component). 

terminal name: the symbolic name for a 
terminal* as assigned by the user. 

terminal table: an ordered collection of 
information consisting of a control field 
for the table and blocks of information on 
each terminal from which a message can 
originate, and each terminals group of ter- 
minals, and processing program to which a 
message can be sent. 

terminal table entry: a block of informa- 
tion on a terminal, group of terminals, or 
processing program; one of the units that 
comprise the terminal table. 

text: that part of the message of con- 
cern to the party ultimately receiving the 
message (that is, the message exclusive of 
the header, or control, information) . 
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INDEX 



Where more than one page reference is 
given, the major reference appears first. 

Access line 12,27 

Access method 7 

Activating communication lines 57,98 

Activation of closed subroutines 92-93 

Addressing 15 

characters 43,46,47,4 8 

terminals 15 
Alternate destination 84 
Answering 15 
Applications 30,31 
Assembling MCPs and MPPs 127 
Assignment of registers 94,129 
Autocall feature 29 
Autoansr feature 29 

Auto Poll facility 9,52,53,8,27,3 3,88 
Auto Poll line 53 

Breakoff error 67,7 

BREAKOFF macro instruction 70,62,124 

Buffer 7,54-57 

definition 54-56 

format 123 

handling 21-24 

insufficient 56 

number 38,56 

pool 54 

size 54-56 
BUFFER macro instruction 56-57 
Buffer request block (BRB) 55-57 

Calling 15 

Canceling messages 70-71 

CANCELM macro instruction 

70-71,64,74,62,124 
Capabilities, QTAM 7,8 
Channel, multiplexer 8,9 
Character set and code correspondence 
135-138 

chart 141-147 
Checkpoint/Restart facility 108-111,19 
Checkpoint data set 34,35 

allocating space for 

defining 110 

opening 110 

closing 110 

keyword operands 35 
CHNGP macro instruction 
CHNGT macro instruction 
CHNGT operator control message 104 
CLOSE macro instruction 112 
Code 

addressing 15 

conversion see Code, translation 

correspondence 135 

destination 20,44,84,85 

device see Code, transmission 

message type 21,62 

source 87,88 

translation 8 8-90 



109-110 



101 
99-100 



translation tables 90 

transmission 32 
Coding format, macro instruction 9-10 
Communication lines 11,12 

activating 57,98-99 

configuration 13,14 

dedicated 12 

enabling 15,58 

error halfword 64-67 

half- duplex 11 

leased 12 

private 12 
Communication line grcup 17 

characteristics 3 3 

data set 3 3,36-41 
Communication network 11-16 

nonswitched 12,13 

switched 12,13,, 27-28 
Component, terminal 10,43 
Components of the LPS 60-61 
Concepts and terminology, 

telecommunications 11-16 
Configuration, network 13,14 
Contention system 15 
Control characters 138-139 
Control formats used by QTAM 113-121 
Control information, QTAM 42 

defining 4 2-50,19 

macro instructions 42-50 
Control station 15 
Control unit failure error 67 
Control unit, telecommunications (TCU) 11 
Conversational mode 79,31,112 
Converting transmission code see C6de, 

translation 
COPYC operator control message 103 
COPYP macro instruction 100 
COPYQ macro instruction 101-102 
COPYT macro instruction 9 9 
COPYT operator control message 104 
COUNTER macro instruction 71,43,46 
CPU usage meter control 171 

DASD destination queue see Queue 
DASD process queue see Queue 
DASD volume 3 2 

Data definition (DD) statement 33 
Data formats used by QTAM 113-121 
Data set 

activation 57-58 

checkpoint 19,24,33-34,57,156 

communication-line group 33,36-42,19,57 

DASD message queues 19, 24, 33,, 35, 57,111 

deactivation 111-112 

definition 3 3-42,19 

initialization 57-60 

machine 11 

message-log 19,33-34^58 
DATESTMP macro instruction 71-72,68,75 
DCB macro instruction 34-42 
Deactivating the telecommunications system 
111,112 
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Dedicated lines 12 

Dead- letter queue see Queue 

Delay, polling see Polling interval 

Delimiter LPS macro instructions 67-70 

summary 126 
Destination 

alternate 84 

code 44,84,85 

invalid 66„84 

queue, DASD see Queue 

queue, main storage see Queue 
Device-access field 43 
Direct access message queues 24 

data set 19,24,33-34,57,111-112 
Direct access storage device (DASD), 
allocation 33 

formatting 128 
DIRECT macro instruction 72,43,81 
Disk queuing rules 158 
Distribution list 44,49,85 
Distribution list entry 44,49 
DLIST macro instruction 49,42,50-51 



Editing of non-IBM terminals 153-154 

carriage return, line feed, new line, 
and end of block 153-154 

end of address 153 

end of transmission 154 
Enabling of line 15,2 6,5 8 
End- of -address (EOA) character 

machine 20,153,155 

program 20,75-76 
End-of-block (EOB) character 76-7 8,153-154 
End-of-text (ETX) character 76-78,154 
End-of-transmission (EOT) character 

20,154,155 
End Receive subgroup 67,62 
End Send subgroup 68,62 
ENDRCV macro instruction 67,62 
ENDREADY macro instruction 60,58 
ENDSEND macro instruction 68,62 
Entry, terminal table see Terminal table 
EOA macro instruction 7 2-73 
EOB macro instruction 73-74,67 
EOBLC macro instruction 74-75,67, 
ERRMSG macro instruction 75-76,43,64-65 
Error checking 64-67,73-75,85 
Error conditions 64-67 
Error correcting 73-75 
Error halfword 66-67 
Error-handling LPS macro instructions 

6 4-65 
Error message, transmission of 75-76 
Error recovery procedures 107-108 
Examining and modifying control system 

status 58,98-102 
Expedite mode 49,31 

Extended BCD interchange code (EBCDIC) 
18,32,88-90 

Functional LPS macro instructions 61-63 
summary 126 

GET macro instruction 24 
Glossary 172-174 
Group code 43-44,86 
Group code entry 43-44,86 



Half-duplex line 11 
Hardware error checking 73 
Hardware timer 8 
Header, message 19 

field skipping 87 

format 19-20,62-63 

incomplete 66 

prefix 20 

scanning 6 3-64 
Header analysis error byte 66 

Idle characters, use cf 82-83,63-64 

Incomplete header 66 

INITIATE mode 78-79,70,75 

Initiate function 79 

Input sequence number 85-86* 40 

Inquiry processing application 31 

Inserting characters in messages 82-83 

Insufficient buffers 56,67 

INTERCPT macro instruction 

76-77,25, 43,62,, 64 
INTERCPT operator control message 104-105 
Interval, polling 27,38 
Interval timer feature 8 
Intervention required error 66*67 
INTREL operator control message 105 
Invalid destination cede 66 w 85 
Invalid operator control messages 106-107 
Invalid source code 66,87 
IODEVICE macro exairple 128 

Leased line 11,12 
Limiting message length 67,70 
Limiting number of messages 83-84 
Line, access 12„27 

Line and station configuration 13,14 
Line connection* establishing 15-16 
Line control block 45 
Line control error byte 66-67 
Line, communication see Communication line 
Line procedure specification (LPS) 
60-63, 17, 18„32 

components of 60-61 

delimiter macro instructions 61-63 

End Receive subgroup 61 

End Send subgroup 61 

error-handling macro instructions 64-65 

functions 61-63 

functional macro instructions 61-63 

header field scanning 63-64 

macro instruction summary 62 

Receive group 18,21,60-61 

Receive Header subgroup 61 

Receive Segment subgroup 61 

Send group 18,60 

Send Header subgroup 61 

Send Segment subgrcup 61 
LOGSEG macro instruction 77-78 
Logging messages 77, 30 

Longitudinal redundancy check (LRC) 73 
LPSTART macro instruction 68-69,62,9 

Machine and device requirements,, QTAM 8 
Machine data set 11 
Kacro instructions 

coding format 9-10 

control information 42-60 

summaries 122-126 
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LPS (see Line procedure specification) 
Main storage - destination queue see Queue 
Main storage - process queue see Queue 
Management of switched lines 25-26 
Message 

canceling 70-71 

code translation 88-90 

control 14-16 

counting 71 

editing 18 

flow 21-24 

format 19-20,62 

header 19-20,62 

intercepting 76-77,104-105 

limiting length of 67,70 

limiting number of 83-84 

logging 77-78,30,33 

priority 78,79 

processing 16 

response 31 

rerouting 84-85 

routing 30-31,32,85 

segment 21-22 

sequence number 85-87,43 

switching 30 

text 19 

translation 88-90 

type 20 

work unit 20,24 
Message control program 32,7,17 

composition 32 

functions 17,32 
Message log data set 33-34 
Message processing applications 30-31 
Message processing program 17,7 

return codes 157 v 

Message switching application 30 
Message type 19,61,80 
Minimum buffer length 56 
Mode, conversational 31,79 
MODE macro instruction 78-8 0,92-93 
Modifying system status 58,98-102 
MSGTYPE macro instruction 8 0*61 
Multiplexer channel 8,9 



Negative response 15,25,26,74 
Network 11-16 

configuration 11-16 

nonswitched 12,13 

switched 12,14,27-28,25 

Offset field in terminal table 116,118 
On-line terminal testing 19,166-170 

test request message 166 

tests available 168 
OPCTL macro instruction 8 0-82 
OPEN macro instruction 5 8-6 
Open subroutine, use of 9 3, -9 6 
Operating environment 18 
Operating system considerations 9 
Operator Awareness Messages 108 
Operator control facility 19 
OPTION macro instruction 45-46,42,43,51 
Optional area terminal table subfields 

45,46,42,43,47 
Outgoing message, sample format 21 
Output sequence number 86,43 



PAUSE macro instruction 82-83,56 
POLL macro instruction 52-54 
POLLIMIT macro instruction 83-84,43,51 
Polling 51-52,15,26,27,59 

address 15,53 

characters 15, 44, 48, 50, 52 

interval 27,38 

limit 51 
Polling list 37,52 

defining 52-54 

examining and modifying 100-101 

example 53 

formats 120 
Positive response 15,25,73-74 
POSTRCV macro instruction 69,62 
POSTSEND macro instruction 69,62 
Prefix (header and text) 24 
Priming a message queue 105 
Priority 

message 78 

receiving and sending 27-28,39,78 

system 18 
Private line 12 
Processing collected data 31 
Processing inquiries 31 
Processing program 7,17 
PROCESS macro instruction 49-51,42,51 
Process program entry 44 
Process queue 

DASD see Queue 

main storage see Queue 
PUT macro instruction 24 

QTAM 

capabilities 7,8,17 

facilities 17,18-19 

general concepts 11-29 

machine and device requirements 8 

message control 14-16 

operating environment 18 

sample programs 159,162 

terminal types supported by 8 
Queue 

control block 101-102 

DASD destination 23-24,158 

DASD process 23-24,158 

dead-letter 85,158 

MS destination 24 

MS process 24 
Queue control block 101-102 
Queuing 

by line 47 

by terminal 46-47 

RCVEITA2 macro instruction 91 
RCVEZSC3 macro instruction 91 
RCVHDR macro instruction 69,62 
RCVSEG macro instruction 69,62 
Receive group of LPS 18,21-24,62 
Receive Header subgroup of LPS 62 
Receive Segment subgroup of LPS 62 
Register assignments 9 4,129 
Register usage 129 
Relative line number 36-37,47,50 
Releasing intercepted messages 105 
RELEASEM operator control message 105 
REROUTE macro instruction 84-85,64 
Response message 31 
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Restarting 110 
Return codes summary 157 
ROUTE macro instruction 85 
Routing messages 32,85 

Sample programs, QTAM 159,162 
Scan pointer 63-64 
Scan routine,, QTAM 93,63-64 
Segment, message 21-24 
Selectric typing element 167 
Send group of LPS 18, 60-61 
SENDHDR macro instruction 69-70,62 
SENDITA2 macro instruction 91-92 
Send Header subgroup of LPS 62 
SENDSEG macro instruction 70 
Send Segment subgroup of LPS 62 
SENDZSC3 macro instruction 91-92 
SEQIN macro instruction 85-86 
SEQOUT macro instruction 86-87 
Sequence checking 85-86 
Sequence number error 85-86 
Should not occur error 66 
Single-terminal entry 43 
SKIP macro instruction 87 
Skipping of header fields 87 
Source code 87 

invalid 87 
SOURCE macro instruction 87 
STARTLN macro instruction 98-99,58,98 
STARTLN operator control message 106 
Station 11 

STOPLN operator control message 105-106 
Suppressing message transmission 76-77 
SWITCH operator control message 106 
Switched lines 

management of 25-26 

terminal table format 116 
Switched network 12,14,27-28 
System generation 29 
System modification 31 

Telecommunications control unit (TCU) 11 
Telecommunications system concepts 11-16 
TERM macro instruction 46-49,43,50 
Terminal 11 



addressing 15 

character sets 135 

component 11,43 

polling 51-54, 15„27 # 59 

types supported by QTAM 7-8 
Terminal table 

defining 4 2-49 

device-access field 43 

distribution- list entry 44„49 

entry formats 113-117 

examining and modifying 99-100,101-102 

example 50-51,118 

group code entry 43-44 

optional area subfield 45-46„43 # 50 

process program entry 44,49 

single terminal entry 43 
Terminal test rules 169-170 
Terminal types supported by QTAM 8 
TERMTBL macro instruction 44-45,50-51 
Text 19 
Text prefix 21 
Threshold values 4 0„ 107,108 

number of data checks 40„107„108 

number of intervention requireds 
40,107,108 

number of time-outs 40,107,108 

number of transmissions 40*107,108 
Time out error 67 

TIMESTMP macro instruction 88,61,78 
Translating transmission code 88-90 
Translation tables 8 9 
TRANS macro instruction 88-90,61 
Transmission code 32,135 

translation 88-90 
Transmission error 66 
TWX- terminal I.D. sequence 48 

User- Written Subroutines within LPS 92-97 

Vertical redundancy check (VRC) 66 



Work area, message processing 
Work unit, message 20, 24 
WTTA polling list 119 
WTTA terminals 8 
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